Follow @Openwall on Twitter for new release announcements and other news
[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Date: Fri, 5 Dec 2014 13:54:35 +0100
From: Hanno Böck <>
Subject: Re: Offset2lib: bypassing full ASLR on 64bit Linux

On Thu, 04 Dec 2014 21:19:04 +0100
Hector Marco <> wrote:

> This is a disclosure of a weakness of the ASLR Linux implementation.
> The problem appears when the executable is PIE compiled and it has an
> address leak belonging to the executable. We named this weakness:
> offset2lib.

Thanks for that.

Two things on that:

Cynics might say "most linux distros aren't vulnerable to ASLR bypass
because they don't use ASLR at all".

Can we please take this as an opportunity to discuss the state of ASLR
on Linux in general? It's pretty sad, afaik Linux was one of the first
to have ASLR (in the form of pax) back in 2001. Today everyone uses
ASLR by default except Linux.

Most distros don't ship pic/pie executables by default. Why? I haven't
done benchmarks, the saying is that this has a notable performance hit
on 32 bit but almost none on 64 bit. If this is true then could we at
least have all major distros enable it on 64 bit?

I wrote a small test .c to print out offset diffs. As expected
printf-main offset is static on normal Linux with pic/pie and random
on a pax-enabled system.

What i found notable: diff-ing two function offsets from different
libraries (I use printf-sin) is alway static, even on Pax. Is this by
design? Can't different libraries be loaded at different offsets in ram?

Hanno Böck


Content of type "application/pgp-signature" skipped

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.