Buffer Overflows — Examples

This is the core demonstration. Two variables sit next to each other in memory. Variable A is 8 bytes. Variable B is 2 bytes and currently holds the value 1,979.

Variable B controls how this application grants access rights:

• If variable B is below 2,000 — the user gets guest rights.
• If variable B is above 24,000 — the user gets administrator rights.

Variable B is currently 1,979. This user has guest rights. Under normal operation, there is no way for the user to change variable B's value. It is not exposed through the application's interface. The developer believed it could only be changed from inside the program itself.

The Overflow

The program allows input to be written into variable A — and it performs no bounds checking. The attacker knows that if they write 9 bytes into variable A, the first 8 bytes fill the buffer, and the 9th byte overflows into variable B.

The attacker needs a 9-character word. They choose: "excessive"

E – X – C – E – S – S – I – V – E = 9 characters.

What Happens Step by Step

The variable A/B demonstration shows what a buffer overflow can achieve in practice. The attacker did not break any encryption. They did not steal any password. They did not need any administrator credentials. They sent a single word — "excessive" — as input.

The consequence was complete privilege escalation because:

• Variable A had no bounds checking — the overflow was possible.
• Variable B sat in adjacent memory and controlled access rights — something valuable was there.
• The same input ("excessive") produces the same result every time — the exploit is repeatable.

All three conditions for a dangerous buffer overflow were present. The developer created a door they did not know existed. The attacker walked through it.

Scenario 1

Question: A program stores a user's input into an 8-byte buffer. Adjacent to that buffer in memory is a 2-byte variable controlling access permissions. The buffer has no bounds checking. An attacker sends 9 bytes of input. What is the MOST LIKELY security consequence?

Answer: The 9th byte overflows into the adjacent permission variable and may change its value to one that grants higher access rights. This is privilege escalation via buffer overflow. The attacker changed a value the developer never intended to be user-modifiable — because the developer did not check the size of input before writing it into the buffer.

Scenario 2

Question: An attacker tries 200 different inputs against a buffer overflow vulnerability. Most attempts crash the application. Only three specific inputs cause the application to change a permission variable in a useful way. One of those inputs produces the exact same result every time it is sent. What is the significance of that one input?

Answer: That input is a repeatable exploit. Repeatability is the key requirement that makes a buffer overflow dangerous. A repeatable overflow can be turned into a tool — automated and deployed against every machine running the vulnerable software. The other 197 inputs that crash the application are denial-of-service at best; the one repeatable input is a reliable privilege escalation exploit.

Scenario 3

Question: A developer argues that a buffer overflow in their application is not dangerous because "the memory next to the buffer is just empty padding — there's nothing important there." Is this a valid defense?

Answer: Not necessarily. Memory layouts can change — a future code update may place a valuable variable adjacent to that buffer. Additionally, the developer may be wrong about what sits adjacent in all execution contexts. However, the developer's point does correctly identify condition 2 of the three conditions for a dangerous overflow: something valuable must be in adjacent memory. If the developer is correct that nothing valuable is adjacent, the overflow cannot produce useful privilege escalation — it may still cause a crash. The proper fix is to add bounds checking to remove condition 1, not to rely on condition 2 remaining absent.