[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Message-ID: <Pine.GSO.4.64.1103211139070.29617@faron.mitre.org>
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:
>> [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
>
>
>
>
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.
