Follow @Openwall on Twitter for new release announcements and other news
[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
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.