Openwall GNU/*/Linux - a small security-enhanced Linux distro for servers
[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Date: Mon, 20 Dec 2010 13:45:29 -0500
From: Dan Rosenberg <dan.j.rosenberg@...il.com>
To: Petr Matousek <pmatouse@...hat.com>, oss-security@...ts.openwall.com, 
	"Steven M. Christey" <coley@...us.mitre.org>
Subject: Re: CVE request: kernel: CAN information leak, 2nd attempt

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.

-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 [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
>
>

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