[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Message-ID: <AANLkTin_XXK8zMNmoBnER7Qj1-H+AQ1TEQ8rGCwBCxa9@mail.gmail.com>
Date: Tue, 23 Nov 2010 12:17:43 -0500
From: Dan Rosenberg <dan.j.rosenberg@...il.com>
To: Steve Grubb <sgrubb@...hat.com>
Cc: oss-security@...ts.openwall.com
Subject: Re: Linux kernel address leaks
> But you can't access kernel memory as a common user unless you already have a second
> bug. That second bug is the CVE. Saying this leak helps escate privs is like saying
> /etc/password leaks account names. You already have to have system access to use that
> info.
>
I'm going to stop nitpicking over CVE definitions, because it's not
the point of this conversation. Let's forget I ever brought it up. I
agree that this isn't a direct threat, but in the interest of being
proactive rather than reactive, fixing this (in combination with other
previously mentioned hardening efforts) would make exploitation of
other vulnerabilities harder.
> That said, why don't upstream kernel allow 0's for the memory addresses? I don't know
> of any tool that uses the memory address information. What user space uses is the
> inode, path, and network address/port fields. (netstat, lsof, netcap)
>
The argument presented to me was that address information can be
helpful in debugging the kernel, which makes sense if you're a
privileged user. I have yet to hear a coherent argument on why
unprivileged users should need this same information, but feel free to
ask the kernel folks - you might get lead around in circles for awhile
though.
-Dan
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.
