[Bug malloc/25945] ASLR information leak via Safe-Linking and tcache or fastbin chunks.

["dj at redhat dot com" <sourceware-bugzilla@sourceware.org>]

https://sourceware.org/bugzilla/show_bug.cgi?id=25945

dj at redhat dot com <dj at redhat dot com> changed:

           What    |Removed                     |Added
----------------------------------------------------------------------------
                 CC|                            |dj at redhat dot com

--- Comment #6 from dj at redhat dot com <dj at redhat dot com> ---
In the grand scheme of things, the big question is, "what can an attacker learn
that the attacker doesn't already know?"  Memory returned by malloc() has
ALWAYS had dirty data in it, and in our case, has always had some form of
pointer in it.  However, if you have the address of the memory itself, you
already know the base address of the heap and the address of the data in each
chunk.  Since the Safe-Linking feature uses the address of the data as the
"randomness", a malicious actor already has everything they need.  Safe-Linking
reduces the ease of using that information, and protects against accidental
corruption, but our implementation in no way hides information.  If we had used
real random bits from the system, I would conclude differently.

I have no objection to clearing internal data before giving memory to the
application, but we must be careful about performance - we don't want to turn
malloc into calloc, but clearing a few words that are likely already in cache
should be fine.  So do we want to clear such data systematically, such as the
proposed patch?  Or in bulk, in malloc() itself, for all chunks?

Note also that these chunks do NOT protect against an attacker calling free()
and using the free'd chunk to access the safe-linking data anyway.

So IMHO this type of patch is a good idea if it protects against accidental
corruption and/or helps us detect such cases (which is what Safe-Linking does),
but if the goal is to protect against malice we should consider a more blanket
solution, one which hides smallbin and largebin pointers as well.

As for the proposed patch, LGTM otherwise ;-)

-- 
You are receiving this mail because:
You are on the CC list for the bug.