Local memory disclosure (was: libpurple CVE UnRequest)

["Steven M. Christey" <coley () rcf-smtp mitre org>]

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:
> >   [1] http://pidgin.im/news/security/?id=50
> >
> >   Upstream patch:
> >   [2] 
> > 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