[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Message-ID: <1985973.3iiugZcOjL@x2>
Date: Wed, 10 Dec 2014 09:25:27 -0500
From: Steve Grubb <sgrubb@...hat.com>
To: oss-security@...ts.openwall.com
Subject: Re: Offset2lib: bypassing full ASLR on 64bit Linux
On Tuesday, December 09, 2014 10:09:02 PM Steve Grubb wrote:
> 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
tcmalloc:
$ ./all-bits
heap 11 bits
pie-heap 26 bits
and just so they are all in one place:
jemalloc:
$ ./all-bits
heap 19 bits
pie-heap 19 bits
glibc:
$ ./all-bits
heap 14 bits
pie-heap 29 bits
Are there any other allocators in common use?
This is quite a range in heap ASLR just based on which library you link
against. Might be nice if some of the low performers gain some more bits of
randomness.
-Steve
> 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.
Confused about mailing lists and their use?
Read about mailing lists on Wikipedia
and check out these
guidelines on proper formatting of your messages.
