The mmap()-ing of the executable and libraries is randomized, the stack and heap are also randomized.

ASLR is controlled system-wide by the value of /proc/sys/kernel/randomize_va_space.

On 32 bit systems “ulimit -s unlimited” disables the randomization of the mmap()-ing because of the following code in the kernel at arch/x86/mm/mmap.c:

static int mmap_is_legacy(void)
{
        if (current->personality & ADDR_COMPAT_LAYOUT)
                return 1;
 
        if (rlimit(RLIMIT_STACK) == RLIM_INFINITY)
                return 1;
 
        return sysctl_legacy_va_layout;
}

Many attacks on ASLR exist including brute force, even on 64 bit systems. Paper

Most modern CPUs protect against executing non-executable memory regions (heap, stack, etc).

This prevents writing shellcode in the buffer after overwriting the return address. However techniques such as return-to-* can be used instead.

gcc's -fstack-protector provides a randomized stack canary/cookie that protects against stack overflows, and reduces the chances of arbitrary code execution via controlling return address destinations. The checking procedures are from libc and may be overwritten in some cases to evade checking. Alternatively, if there is a format string vulnerability the cookie checking function can be overwritten in the GOT table

The GNU C Library heap protector provides corrupted-list/unlink/double-free/overflow protections to the glibc heap memory manager. This stops the ability to perform arbitrary code execution via heap memory overflows that try to corrupt the control structures of the malloc heap memory areas.

MALLOC_CHECK_ =
 0  Silently ignore any issues
 1  Send error message to stderr
 2  abort() is called immediately, killing your program.
 3  Do both '1' and '2' (MALLOC_CHECK_ is a bitfield)

Some pointers stored in glibc are obfuscated via PTR_MANGLE/PTR_UNMANGLE macros internally in glibc, preventing libc function pointers from being overwritten during runtime.

Exec ASLR: Each execution of a program that has been built with “-fPIE -pie” will get loaded into a different memory location. This makes it harder to locate in memory where to attack or jump to when performing memory-corruption-based attacks.

All programs built as Position Independent Executables (PIE) with “-fPIE -pie” can take advantage of the exec ASLR. This protects against “return-to-text” and generally frustrates memory corruption attacks.

Programs built with “-D_FORTIFY_SOURCE=2” (and -O1 or higher), enable several compile-time and run-time protections in glibc:

Hardens ELF programs against loader memory area overwrites by having the loader mark any areas of the relocation table as read-only for any symbols resolved at load-time (“read-only relocations”). This reduces the area of possible GOT-overwrite-style memory corruption attacks.

/proc/$pid/maps With ASLR, a process's memory space layout suddenly becomes valuable to attackers. The “maps” file is made read-only except to the process itself or the owner of the process.

ptrace/gdb can be used to attach to a process, find out needed addresses/data and then detach to construct the payload and feed it to the application

Repeatedly running ldd on an executable can identify the number of random bits of the underlying ASLR. TODO(script for this)

At initial “recon” phase check the binary (and the running kernel if possible) to see enabled security features with checksec.sh (see Tools)

32 bit ABI linux_abi_x32

64 bit ABI linux_abi_x64

peda-gdb Python Exploit Development Assistance for GDB. Presentation slides available here

ROPgadget Gadgets finder and auto-roper

Turing complete ROP compiler (only for PoC)

checksec.sh Security checker for processes/kernel. Many examples here

Ubuntu Security Matrix . Source for some summaries above

Surgically returning to randomized lib(c)