Re: Offset2lib: bypassing full ASLR on 64bit Linux

[Mike Hommey <mh () glandium org>]

> Hi,
>
> 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.
>
> In this scenario, an attacker is able to de-randomize all mmapped
> areas (libraries, mapped files, etc.) by knowing only an address
> belonging to the application and the offset2lib value.
>
> We have built a PoC which bypasses on a 64 bit Linux system, the three
> most widely adopted and effective protection techniques: No-eXecutable
> bit (NX), address space layout randomization (ASLR) and stack smashing
> protector (SSP). The exploit obtains a remote shell in less than one
> second.
>
> We have proposed the ASLRv3 which is a small Linux patch which removes
> the offset2lib weakness.
>
> Details of the weakness, steps to exploit the offset2lib weakness, a
> working proof of concept exploit, recommendations and a demonstrative
> video has been publish at:
> http://cybersecurity.upv.es/attacks/offset2lib/offset2lib.html

If you have the base address of the executable and are able to read any
byte in the process address space, as my reading of the paper suggests,
then you don't even need offsetlib, and no amount of ASLR can save you.

Just read the ELF program headers that you can find at the base address
of the executable to find the PT_DYNAMIC segment. In that segment, find
the DT_DEBUG entry, which will give you a pointer to a r_debug struct,
which definition you can find in /usr/include/link.h.

That struct has a r_map member that gives you a linked list of libraries
the dynamic linker (ld.so) loaded, with the base address for each of
them.

Those data structures are used by gdb, so removing the DT_DEBUG pointer
would break debugging with gdb.

Mike