Date: Mon, 21 Mar 2011 12:02:40 -0400 (EDT) From: "Steven M. Christey" <coley@...-smtp.mitre.org> To: oss-security@...ts.openwall.com Subject: Local memory disclosure (was: libpurple CVE UnRequest) All, Disclosure of "local" memory to another user on the same system could qualify for CVE inclusion, if the memory can contain something sensitive. However, I'm not completely clear on how memory management works at this level, and when this behavior becomes a vulnerability. Note - I'm only talking about local memory disclosure. Remote disclosure is more clear. Doesn't memory "belong" to one process (assuming it's not shared), even in heap management? So another user couldn't access the memory while it's used in the process, and (I guess?) if it's free'd, it's still only accessible to that process (or, alternately, is the region cleared before another program can access it?) If this is the case, then the question becomes what happens to the memory when the vulnerable process exits - is the memory cleared by the kernel, or is it otherwise left alone? What happens if the memory is cached on disk? I did extremely limited experiments in this area a couple years ago, and for the limited set of OSes I tried this on (no idea what libraries), I always got "clean" memory when I ran initial malloc's from a fresh process (later malloc's could contain contents of memory that was previously freed in the same session). That doesn't prove anything, of course... Thanks, Steve On Mon, 21 Mar 2011, Jan Lieskovsky wrote: > > Hello vendors, > > Jan Lieskovsky wrote: >> >> Hello Josh, Steve, vendors, >> >> the following: >>  http://pidgin.im/news/security/?id=50 >> >> Upstream patch: >>  >> http://developer.pidgin.im/viewmtn/revision/info/16f4c309528b82961b169edb8b74b9061db6c471 >> >> Doesn't seem to have a CVE identifier yet. >> >> Could you allocate one? > > John clarified in a reply to my post: > >> Jan, >> >> FYI, we didn't request one because we believed it did not meet the >> guidelines >> for assignment of a CVE identifier. It's a local-only information >> disclosure >> and can't be remotely exploited. >> >> John > > So ignore my earlier post / request. > > Thanks && Regards, Jan. > -- > Jan iankko Lieskovsky / 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.