Date: Mon, 20 Dec 2010 15:43:44 -0500 (EST) From: "Steven M. Christey" <coley@...-smtp.mitre.org> To: Petr Matousek <pmatouse@...hat.com> cc: "Steven M. Christey" <coley@...-smtp.mitre.org>, oss-security@...ts.openwall.com, Dan Rosenberg <dan.j.rosenberg@...il.com> Subject: Re: CVE request: kernel: CAN information leak, 2nd attempt Hmmm, a couple things going on here. I'm fine with associating CVE-2010-3874 with the overflow. But note - if the overflow does not affect any decision-making, bypass protection logic, or cause a DoS (e.g. if certain values of the overflowed field cause a CPU hit), then it's probably OK to treat it as non-security. There hasn't been much security analysis done in semantic overflows and we probably have to treat them on a case-by-case basis. For example - if the last field happens to be a bank account balance, or a flag stating whether a user has some kind of special privilege, then that's a security issue even without memory corruption (or rather, it's still "memory" corruption, just not with the same kinds of management structures that we usually run into currently). Use CVE-2010-4565 for the kernel address leak. - Steve On Mon, 20 Dec 2010, Petr Matousek wrote: > ----- Original Message ----- >> I'm ok with this, but I wanted to point out that the previously >> mentioned heap overflow is a semantic overflow only. Because the >> field that is being overflowed is the last field in a struct that is >> always allocated in a chunk significantly larger than the struct >> itself, the overflow will never result in any kind of corruption, so >> it has essentially no security impact. > > Yes, we are aware of this . Personally I'd call it a mitigation factor > even though I don't have a strong opinion here. Steve, could you please > comment? > >  https://bugzilla.redhat.com/show_bug.cgi?id=649695#c7 > > Petr > >> >> -Dan >> >> On Mon, Dec 20, 2010 at 1:36 PM, Petr Matousek <pmatouse@...hat.com> >> wrote: >>> "The CAN protocol uses the address of a kernel heap object as a proc >>> filename, revealing information that could be useful during >>> exploitation." >>> >>> Reference: >>> https://bugzilla.redhat.com/show_bug.cgi?id=664544 >>> http://seclists.org/oss-sec/2010/q4/103 >>> >>> Credit: Dan Rosenberg >>> >>> ------------ >>> >>> Please note that there has been one attempt to request CVE for this >>> issue already . The problem is that vendors (Red Hat more or less >>> included) used the assigned CVE for the potential heap overflow >>> issue >>> [2, 3] whereas reporter used it for information leak . >>> >>>  http://seclists.org/oss-sec/2010/q4/107 >>>  >>> http://lists.opensuse.org/opensuse-updates/2010-12/msg00026.html >>>  http://www.debian.org/security/2010/dsa-2126 >>>  http://www.cs.brown.edu/people/drosenbe/research.html >>> >>> I'd suggest to keep the CVE-2010-3874 id for the heap overflow which >>> has some (although very limited) security potential and assign a new >>> id >>> for the information leak. >>> >>> Thanks, >>> -- >>> Petr Matousek / Red Hat Security Response Team >>> >>> > >
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