Buffer Overflow
- •
- •
How it works
- •
Determine the buffer's start address and its offset to the target you want to corrupt (another variable, or the saved return address) — either from a disassembly (see Stack Frame Layout) or from a program that discloses its own stack layout directly.
- •
Send padding bytes to fill the buffer and everything between it and the target, then the corrupting value itself.
- •
High addresses [ return addr ] ← target (control-flow hijack) or [ saved rbp ] [ other locals ] ← target (data corruption, no hijack — e.g. login leakage) [ buffer ] ← attacker input starts here Low addresses (rsp)
- •
- •
Limitations
- •
developers are supposed to perform bounds checking; a useful buffer overflow must also be repeatable to reliably compromise a system, which takes time to develop without crashing the target
- •
- •
When to use it
- •
The input operation can write beyond the actual buffer. Check canary placement and other protections separately.
- •
Program prints its own raw stack contents before/after your input → you may not need a separate leak primitive; the offsets and secrets are handed to you.
- •
An adjacent variable or pointer may be a useful target without changing the saved return address.
- •
- •
Examples
- •
Overflow into an adjacent
is_adminvariable to change a later access check without changing the return address. - •
If the saved return address is 56 bytes away,
b'A' * 56 + p64(win)illustrates a basic ret2win Technique payload.
- •
- •
pwntools
- •
payload = b'A' * offset + corrupting_value p.send(payload)
- •
- •
Debugging
- •
disas challenge # find the buffer's rbp-relative offset x/40gx $rsp # inspect the raw stack after sending input
- •
- •
Variants
- •
Adjacent-data corruption (no control-flow hijack): overwrite a variable the program trusts later — a stored password/secret, a flag, a size field — without touching the return address at all.
- •
Return-address overwrite (control-flow hijack): see ret2win Technique for the simplest version (jump to an existing function) and Unavailable reference for when NX blocks straight shellcode and no single existing function does what you need.
- •
Off-by-one: a boundary error writes one extra byte or element. Its impact depends on the adjacent data.
- •
Buffer over-read (reading rather than writing past bounds): the inverse problem — see Memory Disclosure (Info Leak) — often used to leak a canary or address rather than to corrupt anything directly.
- •
Unbounded routines and incorrect length calculations can cause overflows. A bounded routine is only safe when given the correct capacity.
- •
- •
Related
- •
Cards
- •
What is a buffer overflow?
- •
Overwriting a memory buffer so data spills into adjacent, unrelated memory areas
- •
- •
What's the difference between overflowing into a return address vs. an adjacent variable?
- •
Return-address overwrite hijacks control flow (what runs next); adjacent-variable overwrite corrupts data the program trusts later, without changing what code executes.
- •
- •
Why did leaking the raw stack make
Login Leakageeasier than a blind overflow?- •
It handed over the exact offset to the target and its address, removing the need to brute-force or separately leak either one.
- •
- •
Linked references 12
- Arbitrary Read via Pointer Overwrite
- comptia-security-plus-701-professormesser
- Integer Overflow (Signedness Bypass)
- Memory Disclosure (Info Leak)
- Out-of-Bounds Array Access (Index Manipulation)
- pwn-college
- Race Condition
- Read-Counter Manipulation (Canary Skip)
- ret2win Technique
- Stack Canary
- Stack Frame Layout
- Stale Stack Data Leak (Frame Reuse)