SoK: Eternal War in Memory
📜 Abstract
Memory corruption bugs in software written in low-level languages like C or C++ are one of the oldest problems in computer security. The lack of safety in these languages allows attackers to alter the program’s behavior or take full control over it by hijacking its control flow. This problem has existed for more than 30 years and a vast number of potential solutions have been proposed, yet memory corruption attacks continue to pose a serious threat. Real world exploits show that all currently deployed protections can be defeated. This paper sheds light on the primary reasons for this by describing attacks that succeed on today’s systems. We systematize the current knowledge about various protection techniques by setting up a general model for memory corruption attacks. Using this model we show what policies can stop which attacks. The model identifies weaknesses of currently deployed techniques, as well as other proposed protections enforcing stricter policies. We analyze the reasons why protection mechanisms implementing stricter polices are not deployed. To achieve wide adoption, protection mechanisms must support a multitude of features and must satisfy a host of requirements. Especially important is performance, as experience shows that only solutions whose overhead is in reasonable bounds get deployed. A comparison of different enforceable policies helps designers of new protection mechanisms in finding the balance between effectiveness (security) and efficiency. We identify some open research problems, and provide suggestions on improving the adoption of newer techniques.
✨ Summary
Summary
The paper presents a systematization of memory-corruption attacks and defenses for software written in unsafe low-level languages. It models exploitation as a sequence of stages: creating an invalid pointer, dereferencing it, corrupting or disclosing internal state, determining a target value or address, using a corrupted pointer or variable, and finally executing code or using corrupted data. From this model, it distinguishes four attack outcomes: code-corruption attacks, control-flow hijacking, data-only attacks, and information leaks.
The authors classify defenses according to the security policies they enforce. These include memory safety, code integrity, code-pointer integrity, address-space randomization, data-space randomization, control-flow integrity, data-flow integrity, and non-executable data. The analysis shows that deployed mechanisms such as stack cookies, DEP/W⊕X, and ASLR address only portions of the attack process. In particular, code-reuse attacks and information leaks can bypass combinations of these mechanisms.
The paper compares proposed defenses using protection strength, false positives and negatives, performance overhead, memory overhead, source and binary compatibility, and modularity. Its principal conclusion is that stronger deterministic policies—especially complete memory safety, data integrity, and control-flow integrity—are technically more robust, but their adoption is constrained by runtime cost, incompatibility with legacy binaries and libraries, and difficulties supporting separately compiled modules. The paper identifies approximately 10% runtime overhead as a practical adoption boundary, while noting that several stronger approaches impose substantially higher costs.
Influence
The paper’s attack-and-mitigation model was later used explicitly as an analytical framework in CHERI research. A CHERI technical report describes Eternal War in Memory as providing an “excellent categorisation and decomposition” of exploits arising from memory-safety violations and states that its analysis was used as a framework for evaluating CHERI’s effectiveness. (cl.cam.ac.uk) A later CHERI dissertation likewise states that the paper’s model inspired the memory-protection component of a more comprehensive memory-operations framework. (cl.cam.ac.uk) The paper is also repeatedly cited in subsequent memory-safety and security-system research, including later work on memory tagging and kernel security invariants. (usenix.org) These references establish continued research influence; the sources reviewed do not establish that the paper itself directly caused a specific commercial product deployment.