[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Date: Mon, 20 Dec 2010 13:59:46 -0500 (EST)
From: Petr Matousek <pmatouse@...hat.com>
To: "Steven M. Christey" <coley@...us.mitre.org>
Cc: oss-security@...ts.openwall.com, Dan Rosenberg <dan.j.rosenberg@...il.com>
Subject: Re: CVE request: kernel: CAN information leak, 2nd
attempt
----- 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@...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.
Confused about mailing lists and their use?
Read about mailing lists on Wikipedia
and check out these
guidelines on proper formatting of your messages.
