oss-sec mailing list archives
Re: CVE request: kernel: CAN information leak, 2nd attempt
From: "Steven M. Christey" <coley () rcf-smtp mitre org>
Date: Mon, 20 Dec 2010 15:43:44 -0500 (EST)
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 [1]. Personally I'd call it a mitigation factor even though I don't have a strong opinion here. Steve, could you please comment? [1] https://bugzilla.redhat.com/show_bug.cgi?id=649695#c7 Petr-Dan On Mon, Dec 20, 2010 at 1:36 PM, Petr Matousek <pmatouse () redhat 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 [1]. 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 [4]. [1] http://seclists.org/oss-sec/2010/q4/107 [2] http://lists.opensuse.org/opensuse-updates/2010-12/msg00026.html [3] http://www.debian.org/security/2010/dsa-2126 [4] 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
Current thread:
- CVE request: kernel: CAN information leak Dan Rosenberg (Nov 03)
- Re: CVE request: kernel: CAN information leak Eugene Teo (Nov 04)
- CVE request: kernel: CAN information leak, 2nd attempt Petr Matousek (Dec 20)
- Re: CVE request: kernel: CAN information leak, 2nd attempt Dan Rosenberg (Dec 20)
- Re: CVE request: kernel: CAN information leak, 2nd attempt Petr Matousek (Dec 20)
- Re: CVE request: kernel: CAN information leak, 2nd attempt Steven M. Christey (Dec 20)
- Re: CVE request: kernel: CAN information leak, 2nd attempt Dan Rosenberg (Dec 20)
- CVE request: kernel: CAN information leak, 2nd attempt Petr Matousek (Dec 20)
- Re: CVE request: kernel: CAN information leak Eugene Teo (Nov 04)