Date: Fri, 26 Sep 2008 18:16:31 -0400 (EDT) From: "Steven M. Christey" <coley@...us.mitre.org> To: oss-security@...ts.openwall.com cc: coley@...re.org Subject: Re: CVE-2008-4113 update: kernel: sctp: fix random memory dereference with SCTP_HMAC_IDENT option On Thu, 25 Sep 2008, Eugene Teo wrote: > Hi Steve, > > The first three references to CVE-2008-4113 are incorrect. Please > update the CVE with the following references: > > http://marc.info/?l=linux-sctp&m=121986743009093&w=2 > http://marc.info/?l=linux-sctp&m=121986743209110&w=2 > >  http://cve.mitre.org/cgi-bin/cvename.cgi?name=CVE-2008-4113 This was in reference to the TKADV2008-007 advisory. I guess the question becomes - TKADV2008-007 talks about separate issues, one involving crashes by calling the API functions when SCTP-AUTH is disabled (CVE-2008-3792), and another involving SCTP_HMAC_IDENT and a length value for sctp_getsockopt_hmac_ident. CVE-2008-4113 is anchored on what's specified in TKADV2008-007: The Linux Kernel contains an information disclosure vulnerability while parsing the IOCTL SCTP_HMAC_IDENT... if (get_user(len, optlen)) <--  ... retval = sctp_getsockopt_hmac_ident(sk, len, optval, optlen); <--  which seems different from this one: http://marc.info/?l=linux-sctp&m=121986743209110&w=2 "The number of identifiers needs to be checked against the option length. Also, the identifier index provided needs to be verified to make sure that it doesn't exceed the bounds of the array." and this one: http://marc.info/?l=linux-sctp&m=121988176932559&w=2 The bonds check to prevent buffer overlflow was not exactly right. It still allowed overflow of up to 8 bytes which is sizeof(struct sctp_authkey)." So Eugene, it sounds like the issues that you found were variants of the issue reported for the sctp_getsockopt_hmac_ident (a different function) by TKADV2008-007 for CVE-2008-4113. Do we need new CVE identifiers? Or am I missing something? - Steve
Powered by blists - more mailing lists
Please check out the Open Source Software Security Wiki, which is counterpart to this mailing list.
Powered by Openwall GNU/*/Linux - Powered by OpenVZ