Re: CVE request: kernel: CAN information leak, 2nd attempt

[Dan Rosenberg <dan.j.rosenberg () gmail com>]

Seems reasonable as a general rule.  For the sake of absolute clarity,
nothing is being overflowed except the boundary defined by the
structure's declaration.  The last field of the structure corresponds
to the name of a /proc entry, and is sized at 9 bytes.  On x86-64, up
to 17 bytes can be copied into this field, but since there's nothing
after the field but empty space in the heap chunk, nothing bad
happens.  Absolutely no real data of any kind is ever overwritten.

-Dan

On Mon, Dec 20, 2010 at 3:43 PM, Steven M. Christey
<coley () rcf-smtp mitre org> wrote:
> 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