GDB and ASLR: why a stable address can be a debugging artefact

An address that stays identical across ten GDB runs can still move every time you launch the same binary normally. Before treating that address as a useful exploit primitive, check whether the debugger has made the layout predictable for you.

On supported targets including GNU/Linux, GDB defaults to disabling address-space randomization for programs it starts. That is convenient for debugging, but easy to mistake for a property of the binary. Here is a small Linux lab that makes the difference visible.

1. Build something whose addresses you can compare

You need GCC, GDB and a Linux environment that permits local debugging. Save this as layout.c:

#include <stdio.h>

static int marker;

int main(void)
{
    int local = 0;
    printf("image=%p stack=%p\n", (void *)&marker, (void *)&local);
    return 0;
}

Build it explicitly as a position-independent executable (PIE), then launch it twice:

gcc -g -O0 -fPIE -pie layout.c -o layout
cat /proc/sys/kernel/randomize_va_space
./layout
./layout

The image pointer belongs to the executable's static storage; stack points to a local variable. With ASLR enabled and supported, both should vary across repeated launches. Compare several runs rather than treating one repeated value as proof.

The kernel's randomize_va_space documentation distinguishes:

• 0: process address-space randomization off.
• 1: randomizes the mmap base, stack and VDSO; also the code start of PIE binaries.
• 2: additionally enables heap randomization.

Reading this setting does not change it. If it is 0, this lab will not demonstrate normal ASLR until you use an appropriately configured environment.

2. Compare GDB's two launch modes

Start gdb ./layout, then enter:

show disable-randomization
set disable-randomization on
run
run
set disable-randomization off
run
run

The double negative matters:

• on asks GDB to disable randomization. When that request succeeds, repeated runs under otherwise unchanged conditions should give stable addresses in this example.
• off leaves the executable's normal randomization behavior alone. With system ASLR enabled, addresses should vary again. It does not force ASLR on if the system has it disabled.

If GDB reports that it could not disable randomization, those runs are not a valid ASLR-off baseline. These settings concern programs GDB launches; attaching to an existing process does not rebuild its address space.

The GDB manual's launch settings document the default, both commands and the gcc -fPIE -pie build option.

3. Take the right lesson into crash analysis

A stable address under GDB is not evidence that ASLR has been bypassed. First establish how the process was launched and which mappings actually move.

For a PIE binary, distinguish an object's offset within the image from its absolute runtime address. The offset can stay constant for the same build while the image's load address changes. Hard-coding the latter from an ASLR-disabled debugging run quietly bakes the debugger's conditions into your reproducer.

Also, set disable-randomization off is not a promise that a GDB launch exactly matches a shell launch. Arguments, environment and launch wrappers can still differ; the GDB manual describes those controls too. A stack pointer need not match between the two even when their ASLR policy matches.

When sharing a “works in GDB, fails outside it” result, include the exact binary/build, launch command, randomize_va_space value and show disable-randomization output. That turns an address screenshot into something another person can meaningfully investigate.