Chapter 35 Key Takeaways: Buffer Overflows and Memory Corruption

  1. A buffer overflow is C doing exactly what you told it to do: writing past the end of a buffer overwrites adjacent memory. The compiler inserts no bounds check. On the stack, that adjacent memory is the saved RBP and then the return address — the CPU will jump wherever the return address points when ret executes.

  2. The offset to the return address is deterministic: for a function with char buf[N] and a standard x86-64 frame, the offset from buf[0] to the return address is N + 8 (N bytes of buffer plus 8 bytes of saved RBP). This can be confirmed with GDB's cyclic pattern tool.

  3. Shellcode must be position-independent and null-byte-free: position-independent because stack addresses are unpredictable (ASLR); null-byte-free because many overflow vectors use string functions that terminate at \0. The classic execve("/bin/sh") shellcode encodes the path by pushing it to the stack at runtime and uses mov al, 59 instead of mov rax, 59 to avoid zero bytes in the immediate.

  4. NOP sleds were a reliability technique, not a fundamental component: a sequence of NOP (0x90) instructions before shellcode allowed imprecise landing before ASLR made addresses unpredictable. Understanding NOPs as a defensive indicator (malware may still use them for historical-compatibility shellcode) is more relevant today than understanding them as an offensive technique.

  5. Format string vulnerabilities arise from passing user-controlled data as the format string: printf(user_input) lets the attacker use %p to read stack contents and %n to write values to memory. The fix is always printf("%s", user_input). Modern compilers warn about this with -Wformat-security.

  6. Use-after-free is now the dominant heap exploitation technique: accessing memory through a pointer after it has been freed can be exploited when the attacker can control what gets allocated at the freed address. If a function pointer is at the freed location, controlling the new allocation contents means controlling execution.

  7. Heap chunk headers in glibc contain allocator metadata: prev_size, size, and (when freed) fd/bk free list pointers. Overflowing into adjacent heap chunk headers corrupts these pointers, which are followed during subsequent malloc/free operations, potentially allowing controlled writes.

  8. The Morris Worm (1988) established the template for network exploitation: buffer overflow in fingerd's gets() call → shellcode injection → shell execution → lateral movement. The response established CERT/CC, led to gets() deprecation, and accelerated secure coding research. Every mitigation in Chapter 36 traces its lineage to exploits like this.

  9. Every dangerous C function has a safe alternative: gets() → fgets(); strcpy() → strlcpy(); sprintf() → snprintf(); scanf("%s") → scanf("%63s"). The safe versions require a size argument and respect it.

  10. AddressSanitizer (-fsanitize=address) catches memory corruption at runtime: buffer overflows, use-after-free, double-free, and heap corruption are detected immediately with a clear report including the allocation and use locations. Use ASan in testing; it is essential for finding vulnerabilities before attackers do.

  11. The three conditions required for classic shellcode injection no longer hold on modern systems: executable stack (defeated by NX/DEP), predictable addresses (defeated by ASLR), and no canary detection (defeated by stack canaries). Modern exploitation requires either bypassing multiple mitigations or using techniques that do not inject code (ROP, Chapter 37).

  12. Double-free corrupts allocator metadata in glibc: freeing the same pointer twice puts a chunk on the free list twice, corrupting the fd field. Modern glibc has double-free detection, but custom allocators often do not.

  13. Heap spraying and grooming are techniques for controlling heap layout: allocating many objects of a specific size to force the allocator to return predictable addresses, or arranging allocations so that a freed object will be reallocated adjacent to an attacker-controlled buffer. These make UAF exploitation reliable.

  14. Memory-safe languages prevent these vulnerabilities by design: Rust's borrow checker prevents use-after-free at compile time; bounds checks in Java, Go, Python, and C++ STL containers prevent buffer overflows at runtime. Choosing the right tool for the job includes considering the security properties of the memory model.

  15. Defense in depth applies to memory corruption: no single mitigation is sufficient. Stack canaries catch overwrites; NX prevents shellcode; ASLR makes addresses hard to predict; AddressSanitizer catches bugs in testing; static analysis catches dangerous patterns in code review; memory-safe languages prevent whole classes of bugs. Together these layers make exploitation very difficult even when vulnerabilities exist.