Vulnerabilities and Exploitation

Vulnerabilities are flaws in software that violate its security assumptions; exploitation is the craft of turning such a flaw into attacker-controlled behavior, from data leakage to full code execution.

Definition

A vulnerability is a weakness in a system that an attacker can use to violate its security policy; an exploit is a technique or program that takes advantage of a specific vulnerability to achieve unauthorized effects.

Scope

This topic covers the major vulnerability classes — memory-corruption bugs (buffer overflows, use-after-free), injection, integer errors, and logic flaws — and the techniques to exploit them, including control-flow hijacking and return-oriented programming. It also covers the mitigations that raise the cost of exploitation (ASLR, DEP/NX, stack canaries, control-flow integrity). It excludes secure-development practices and web-specific vulnerabilities, which are treated in sibling topics.

Core questions

• What categories of software flaws create exploitable vulnerabilities?
• How does a memory-corruption bug get turned into control over a program?
• What is return-oriented programming and why does it defeat simple defenses?
• How do mitigations like ASLR, DEP, and stack canaries raise the exploitation bar?
• Why does the 'arms race' between exploitation and mitigation persist?

Key concepts

• buffer overflow
• use-after-free
• integer overflow
• injection
• control-flow hijacking
• return-oriented programming
• shellcode
• ASLR, DEP/NX, stack canaries
• control-flow integrity

Key theories

Control-flow hijacking

Many exploits corrupt a code pointer (such as a return address or function pointer) to redirect execution to attacker-chosen code, the canonical example being the stack buffer overflow that overwrites a saved return address.

Mitigations and the exploitation arms race

Defenses such as non-executable memory, address-space layout randomization, stack canaries, and control-flow integrity each block a class of techniques, prompting new attacks (return-oriented programming, information leaks) in a continuing escalation.

Mechanisms

A classic stack overflow writes past a buffer's bounds, overwriting the saved return address so that, when the function returns, execution jumps to attacker-supplied shellcode. Mitigations broke this: non-executable memory (DEP/NX) stopped running injected code, prompting return-oriented programming that chains existing code fragments; address-space layout randomization hid target addresses, prompting information-leak primitives to defeat it. Control-flow integrity and memory-safe languages aim to close these classes entirely.

Clinical relevance

Exploitable vulnerabilities are the raw material of real attacks: memory-safety bugs account for a majority of critical vulnerabilities in major browsers and operating systems, zero-day exploits are bought, sold, and used in espionage and crime, and the discipline drives defensive engineering, responsible disclosure, bug bounties, and the push toward memory-safe languages like Rust.

Evidence & guidelines

Vulnerability classes are cataloged in MITRE's CWE and tracked individually as CVEs with CVSS severity scores. Studies from major vendors (Microsoft, Google) report that around 70% of severe vulnerabilities stem from memory unsafety, motivating guidance toward memory-safe languages and the deployment of mitigations (ASLR, CFI) by default in modern platforms.

History

Exploitation entered the public eye with the 1988 Morris worm's buffer overflow and was systematized by Aleph One's 1996 'Smashing the Stack for Fun and Profit'. Each defense provoked a response: DEP led to return-into-libc and Shacham's return-oriented programming (2007); ASLR led to leak-based bypasses. The 2013 'Eternal War in Memory' survey framed the ongoing arms race, which continues to drive both new mitigations and the adoption of memory-safe languages.

Key figures

• Elias Levy (Aleph One)
• Hovav Shacham
• Dawn Song
• Ross Anderson
• Halvar Flake

Seminal works

• aleph1996
• szekeres2013
• anderson2020

Frequently asked questions

What is a zero-day vulnerability?

A zero-day is a vulnerability unknown to the software's defenders (and unpatched) at the time it is exploited, giving them zero days to prepare. Such flaws are especially valuable to attackers because no fix or signature exists yet.

Why are memory-safe languages promoted as a solution?

Memory-safe languages (like Rust) prevent whole classes of bugs — buffer overflows, use-after-free — at compile or run time, eliminating the most common source of severe vulnerabilities rather than merely making each one harder to exploit.