Why Fixed Memory Addresses Are a Security Problem

Every running Linux process has a Virtual Address Space (VAS). This space contains:

• The program’s own code (text segment)
• Global and static variables (data/BSS segments)
• The heap (for dynamic memory allocations)
• Shared library mappings (like glibc)
• The stack
• The vDSO page (a kernel optimization for fast system calls)

Before ASLR existed, all of these regions loaded at predictable, fixed virtual addresses every single time a program ran. For a given architecture and software version, you could look up exactly where system() from glibc would be mapped in any process on that machine — tools like objdump, readelf, and nm made this trivial.

An attacker exploiting a buffer overflow vulnerability could use this knowledge to redirect program execution straight into a dangerous function. This attack style is called a return-to-libc attack. ASLR directly counters it by making memory layout unpredictable.

How ASLR Works – Randomization Under the Hood

ASLR works on a simple but powerful idea: instead of placing memory segments at their default base addresses, the Linux kernel applies a random page-aligned offset to each segment at process launch time. The word “page-aligned” means the offset is always a multiple of the system’s page size (typically 4096 bytes on x86), because memory can only be mapped in page-sized units.

The randomized regions in user space include:

• Shared library load addresses — glibc, libpthread, and every other shared object
• mmap-based allocations — any malloc() call requesting more than 128 KB goes through mmap(2) internally, and its result is randomized
• Stack start address
• Heap start address (with ASLR value = 2, see below)
• vDSO page — the virtual Dynamic Shared Object that the kernel maps into every process for fast system call execution

Because all of these regions shift by a different random amount on each execution, an attacker who learns the address of one symbol in one run of a program cannot use that knowledge in a subsequent run — the address changes every time.

Controlling User-Mode ASLR – The randomize_va_space Tunable

Linux exposes ASLR control through a procfs pseudo-file you can read and write as root:

/proc/sys/kernel/randomize_va_space

This tunable accepts three integer values. The table below explains each one:

On any standard Linux distribution today, this value will be 2 by default. You can verify it on your system with:

# Check current ASLR setting
cat /proc/sys/kernel/randomize_va_space

To temporarily change it (requires root, resets on reboot):

# Disable ASLR temporarily (testing/debugging only)
echo 0 | sudo tee /proc/sys/kernel/randomize_va_space

# Enable partial ASLR
echo 1 | sudo tee /proc/sys/kernel/randomize_va_space

# Re-enable full ASLR (recommended)
echo 2 | sudo tee /proc/sys/kernel/randomize_va_space

Seeing ASLR in Action – A Practical Demonstration

The most direct way to observe ASLR working is to print the address of a function or a local variable from two separate runs of a program and compare the results.

/* File: check_aslr.c
 * Demonstrates ASLR by printing the address of a local variable
 * (on the stack) and the address of a glibc function across runs.
 * Compile: gcc -o check_aslr check_aslr.c
 */

#include <stdio.h>
#include <stdlib.h>

int main(void)
{
    int local_var = 42;

    /* Stack address changes each run when ASLR is active */
    printf("Stack variable address  : %p\n", (void *)&local_var);

    /* Heap address changes each run when ASLR value is 2 */
    void *heap_ptr = malloc(64);
    printf("Heap allocation address : %p\n", heap_ptr);

    /* glibc function address changes each run */
    printf("Address of printf()     : %p\n", (void *)printf);

    free(heap_ptr);
    return 0;
}

When ASLR is active (value 2), running this program twice gives completely different addresses each time. When ASLR is disabled (value 0), the addresses are identical across every run.

To demonstrate this from the shell:

# Run twice in a row with ASLR enabled and compare outputs
gcc -o check_aslr check_aslr.c
./check_aslr
./check_aslr

# Now disable ASLR and try again
echo 0 | sudo tee /proc/sys/kernel/randomize_va_space
./check_aslr
./check_aslr

# Re-enable ASLR when done
echo 2 | sudo tee /proc/sys/kernel/randomize_va_space

You will clearly see addresses differ between runs with ASLR on, and stay identical with ASLR off. This is the core behavior that defeats predictable-address attacks.

Limitations of ASLR – It Is Statistical, Not Absolute

ASLR is a strong defense but it is not a perfect one. The randomization depends on how many bits of entropy are available for the offset. On 32-bit systems, the virtual address space is only 4 GB, and the number of possible random positions is limited — an attacker with enough attempts (a brute-force approach) might guess a valid address.

On 64-bit systems the address space is vastly larger, which gives ASLR much stronger entropy, but even there:

• Not all bits of the address are randomized — page alignment reduces the bit count available for randomization
• An information leak vulnerability (such as a format string bug) can expose the actual runtime addresses to an attacker, completely defeating ASLR for that process
• Brute-force attacks remain possible when a crashed process is quickly restarted without re-randomizing

Common Mistakes When Working with ASLR