Hexcellents CTF Wiki


Exploit mitigation techniques and defeat methods

Address space layout randomization

  • 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

Non-executable stack (NX)

  • 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.

Stack protector (ProPolice)

  • 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

Heap protector

  • 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.
     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)

Pointer obfuscation

  • 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.

Position Independent Executable

  • 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.

Fortify Source

  • Programs built with “-D_FORTIFY_SOURCE=2” (and -O1 or higher), enable several compile-time and run-time protections in glibc:
    • expand unbounded calls to “sprintf”, “strcpy” into their “n” length-limited cousins when the size of a destination buffer is known (protects against memory overflows).
    • stop format string “%n” attacks when the format string is in a writable memory segment.
    • require checking various important function return codes and arguments (e.g. system, write, open).
    • require explicit file mask when creating new files.


  • 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.

Information leakage

  • /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)

Linux specific


Various Papers and other Docs

kb/exploiting/home.txt · Last modified: 2013/09/18 17:35 by rcaragea
[unknown link type]Back to top