Linux – The pie base address is fixed in gdb

The pie base address is fixed in gdb… here is a solution to the problem.

The pie base address is fixed in gdb

I’m using ubuntu-13.10 with ASLR enabled

root@ubuntu:/home/meltdown# cat /proc/sys/kernel/randomize_va_space 
2

I compiled a simple hello world program with the gcc -pie option.
If I run this program alone, the base address of the PIE executable is random. Like this.

root@ubuntu:/home/meltdown# cat /proc/8872/maps
b758b000-b758c000 rw-p 00000000 00:00 0 
b758c000-b773a000 r-xp 00000000 08:01 10749216   /lib/i386-linux-gnu/libc-2.17.so
b773a000-b773c000 r--p 001ae000 08:01 10749216   /lib/i386-linux-gnu/libc-2.17.so
b773c000-b773d000 rw-p 001b0000 08:01 10749216   /lib/i386-linux-gnu/libc-2.17.so
b773d000-b7740000 rw-p 00000000 00:00 0 
b7752000-b7756000 rw-p 00000000 00:00 0 
b7756000-b7757000 r-xp 00000000 00:00 0          [vdso]
b7757000-b7777000 r-xp 00000000 08:01 10749212   /lib/i386-linux-gnu/ld-2.17.so
b7777000-b7778000 r--p 0001f000 08:01 10749212   /lib/i386-linux-gnu/ld-2.17.so
b7778000-b7779000 rw-p 00020000 08:01 10749212   /lib/i386-linux-gnu/ld-2.17.so
b7779000-b777a000 r-xp 00000000 08:01 14942231   /tmp/a
b777a000-b777b000 r--p 00000000 08:01 14942231   /tmp/a
b777b000-b777c000 rw-p 00001000 08:01 14942231   /tmp/a
bf9f4000-bfa15000 rw-p 00000000 00:00 0          [stack]

However, if I debug this program with gdb, the PIE base address is always the same (80000000).

root@ubuntu:/home/meltdown# cat /proc/8840/maps
80000000-80001000 r-xp 00000000 08:01 14942231   /tmp/a
80001000-80002000 r--p 00000000 08:01 14942231   /tmp/a
80002000-80003000 rw-p 00001000 08:01 14942231   /tmp/a
b7e12000-b7e13000 rw-p 00000000 00:00 0 
b7e13000-b7fc1000 r-xp 00000000 08:01 10749216   /lib/i386-linux-gnu/libc-2.17.so
b7fc1000-b7fc3000 r--p 001ae000 08:01 10749216   /lib/i386-linux-gnu/libc-2.17.so
b7fc3000-b7fc4000 rw-p 001b0000 08:01 10749216   /lib/i386-linux-gnu/libc-2.17.so
b7fc4000-b7fc7000 rw-p 00000000 00:00 0 
b7fdb000-b7fdd000 rw-p 00000000 00:00 0 
b7fdd000-b7fde000 r-xp 00000000 00:00 0          [vdso]
b7fde000-b7ffe000 r-xp 00000000 08:01 10749212   /lib/i386-linux-gnu/ld-2.17.so
b7ffe000-b7fff000 r--p 0001f000 08:01 10749212   /lib/i386-linux-gnu/ld-2.17.so
b7fff000-b8000000 rw-p 00020000 08:01 10749212   /lib/i386-linux-gnu/ld-2.17.so
bffdf000-c0000000 rw-p 00000000 00:00 0          [stack]

Can anyone explain why?

Solution

By default, the gdb debugger turns off address space layout randomization. This is partly to ensure that you always debug the same environment. From gdb documentation (search disable-randomization):

This option is useful for multiple debugging sessions to make the execution better reproducible and memory addresses reusable across debugging sessions.

This is the same reason I use srand(42) instead of srand(time(NULL)) at the beginning of the code (only when debugging) – it provides an absolutely consistent environment from run to run, making debugging easier.

If you have a very subtle error that is caused by the location of your code in the address space, it may behave differently in the debugger unless ASLR is disabled.

You can use:

set disable-randomization off

According to the gdb documentation, re-enable ASLR before starting the program from gdb.

I

suspect you can also use gdb to attach to an already running process (this is under the influence of ASLR) instead of having gdb start your program from scratch, I tend to use ~/.gdbinit to force the activation of ASLR.

Related Problems and Solutions