[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Message-Id: <201011231212.18654.sgrubb@redhat.com>
Date: Tue, 23 Nov 2010 12:12:18 -0500
From: Steve Grubb <sgrubb@...hat.com>
To: oss-security@...ts.openwall.com
Cc: Dan Rosenberg <dan.j.rosenberg@...il.com>
Subject: Re: Linux kernel address leaks
On Tuesday, November 23, 2010 12:00:51 pm Dan Rosenberg wrote:
> I don't think it's appropriate to use CVEs as a blackmailing tool, and
> I don't actually think these issues need CVEs. But claiming that it
> would be inappropriate to assign them because they're not "security
> problems" is a bit misguided. We're not talking about leaking
> function addresses here - we're talking about leaking the addresses of
> live kernel data structures, which in my opinion is more of a risk.
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.
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)
-Steve
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.
