Re: Offset2lib: bypassing full ASLR on 64bit Linux

[Steve Grubb <sgrubb () redhat com>]

On Tuesday, December 09, 2014 08:03:10 PM Daniel Micay wrote:
> On 09/12/14 11:18 AM, Steve Grubb wrote:
> > 4) Then I started wondering about the heap when you use other memory
> > manager libraries such as jemalloc. This turned out to be interesting.
> > You get about 19 bits of randomness using it. Its not as bad as non-PIE
> > glibc but not as good as PIE glibc. You also got the same amount of
> > randomness whether the app was PIE or not. This is an area ripe for more
> > experimenting, exploiting, and patching. Supposedly some of these heap
> > managers use mmap as the underlying allocator. So, why aren't they
> > getting 29 bits, too? :-)
>
> Your measurement of the difference is quite accurate.

There's other allocators, too.

libtalloc:
$ ./all-bits 
heap       14 bits
pie-heap   29 bits

Hoard:
$ ./all-bits 
heap       25 bits
pie-heap   25 bits

Different allocators, different strategies, different randomness. While people 
are thinking about this, it might be a good time to check everything that's 
popular. Hmmm...now that I think about it, I haven't looked for address bias 
in the last samples....  :-)

-Steve

> The page multiple constraint zaps 12 potential bits of entropy, but
> jemalloc's 4M chunk alignment increases that to 22 bits. I'm not sure
> what can be done about it because there's a very strong performance case
> for the design.
>
> I sent in a fix for the MALLOC_CONF part of this at least, so an
> attacker won't be able to reduce it further:
>
> https://github.com/jemalloc/jemalloc/pull/174

Attachment: signature.asc
Description: This is a digitally signed message part.