Date: Tue, 09 Dec 2014 22:09:02 -0500 From: Steve Grubb <sgrubb@...hat.com> To: oss-security@...ts.openwall.com Cc: Daniel Micay <danielmicay@...il.com> Subject: Re: Offset2lib: bypassing full ASLR on 64bit Linux 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 Download attachment "signature.asc" of type "application/pgp-signature" (182 bytes)
Powered by blists - more mailing lists
Please check out the Open Source Software Security Wiki, which is counterpart to this mailing list.