Information Security
Exploit Development: Buffer Overflow
EternalBlue. 2017. The NSA develops an exploit for a buffer overflow in the SMBv1 protocol of Windows (CVE-2017-0144). Shadow Brokers leak it to the internet. WannaCry ransomware uses EternalBlue to spread to 200,000 systems in 150 countries in 72 hours. NotPetya follows - $10 billion in damages. A single buffer overflow vulnerability, unpatched for months after Microsoft released the fix, caused the most financially damaging cyberattack in history.
- **EternalBlue 2017 (CVE-2017-0144)**: buffer overflow in SMBv1 - WannaCry, NotPetya, 200K victims, $8 billion in damages.
- **Log4Shell 2021 (CVE-2021-44228)**: heap-based exploit via JNDI lookup - CVSS 10.0, billions of vulnerable servers.
- **Pwn2Own 2023**: Chrome sandbox escape via V8 UAF + Linux kernel privilege escalation - $180,000 payout for the exploit chain.
Stack Buffer Overflow: Overwriting Return Addresses
1988: the Morris Worm exploited a buffer overflow in fingerd to infect 6,000 Unix systems - 10% of the entire internet at the time. 2003: MS Blaster (CVE-2003-0352) used a buffer overflow in Windows RPC to spread to millions of systems within days. The root cause in both cases: writing user-controlled data to a fixed-size buffer without length checking.
Stack Smashing Protector (-fstack-protector-all) inserts a random canary value between the buffer and return address. Before returning, the function checks if the canary was modified. Bypass: if the program also has a format string vulnerability, %x%x%x can read the stack and leak the canary value, then the overflow includes the correct canary.
Stack canary protection is enabled. The attacker also found a format string vulnerability in the same function. How do these combine?
Heap Overflow and Use-After-Free
Stack overflow as a technique is largely mitigated by default compiler protections. Modern exploits target the heap: dynamically allocated memory via malloc/new. The most common heap vulnerability in modern browsers and complex applications is Use-After-Free (UAF): accessing a pointer after the object it referenced has been freed.
Browser UAF exploits follow a pattern: find a UAF in the JavaScript engine, use heap spray to place shellcode or a fake object at the freed address, trigger the UAF to execute. Chrome's V8 engine receives multiple UAF bug reports per month. The V8 team uses AddressSanitizer (ASAN) and fuzzing to find UAFs before attackers do.
A browser has a UAF vulnerability in the JavaScript engine. ASLR is enabled. How does an attacker proceed?
ROP: Return-Oriented Programming
NX/DEP prevents executing code from the stack or heap. Shellcode does not work. ROP (Return-Oriented Programming) bypasses this: instead of injecting new code, the attacker chains existing code snippets (gadgets) already present in the program's executable memory. Each gadget ends with a ret instruction, which transfers control to the next gadget address on the stack.
ROPgadget, pwntools, and peda are standard tools for building ROP chains in CTF competitions and professional penetration testing. pwntools is a Python library that automates exploit development: ELF parsing, gadget search, process interaction, and remote socket handling. The Sigreturn-Oriented Programming (SROP) variant uses the sigreturn syscall to set all registers at once with a single gadget.
NX/DEP is enabled. Full RELRO is enabled. Stack canary is enabled. ASLR is enabled. Is a ROP attack still possible?
ASLR Bypass: Information Leak Techniques
ASLR randomizes base addresses of the stack, heap, and libraries on each execution. Hardcoded addresses in an exploit do not work. But ASLR has limited entropy on 32-bit systems (16 bits = 65,536 possible locations - brute-forceable in seconds). On 64-bit systems, the standard bypass is an information leak that reveals an address, allowing calculation of all other addresses.
PIE (Position Independent Executable) randomizes the program's own binary base address in addition to libraries. Without PIE, code segment gadgets are at fixed addresses even with ASLR enabled - a common misconfiguration that makes exploitation significantly easier. Modern distributions compile most system binaries with PIE by default.
64-bit Linux with ASLR enabled but no PIE. The attacker has no information leak. Is a ROP attack possible?
Key Ideas
- **Stack overflow**: overwrites the return address when writing past a fixed-size buffer. Defense: stack canary + NX + ASLR + safe string functions.
- **UAF (Use-After-Free)**: accessing freed memory after it has been reallocated. Most common exploit type in modern browser bugs. Set freed pointers to NULL.
- **ROP**: chains existing code gadgets (ending in ret) to execute arbitrary logic without injecting shellcode. Bypasses NX/DEP. Requires knowing gadget addresses.
- **ASLR bypass**: information leak reveals an address, allowing calculation of all others. Without PIE, program binary gadgets are at fixed addresses even with ASLR.
Related Topics
Exploit development connects to memory safety and reverse engineering:
- Memory Safety — Rust, Go, and Swift eliminate buffer overflows at the language level through bounds checking and ownership.
- Reverse Engineering — Analyzing binaries to find gadgets, understand memory layouts, and locate vulnerable functions.
- OS Security: Linux Hardening — ASLR, NX, and seccomp are OS-level mitigations that raise the cost of exploiting buffer overflows.
Вопросы для размышления
- A legacy C application uses sprintf() throughout. A full rewrite is not feasible. What is the minimum change set that meaningfully reduces the buffer overflow attack surface?
- ASLR and PIE are both enabled. An attacker still exploits the binary. What categories of information leaks would make this possible?
- Why do modern browser security teams invest heavily in fuzzing JavaScript engines specifically, given that browsers also have native code throughout?