Not Quite Write: On the Effectiveness of Store-Only Bounds Checking
summary
Store-only bounds checking omits read checks but invalid reads still let attackers control subsequent writes by loading crafted pointers and metadata, so store-only defenses are bypassable. The paper reproduces bypasses on SoftBound, shows Intel’s Intel MPX is even more breakable, and finds the necessary preconditions common across 1,000 repositories from GitHub. Experiments are open-source and include concrete exploits and microbenchmarks. A counterexample that resists these bypasses is data flow integrity, which enforces allowed referents at compile time.
AI-written summary · about
chapters (18)
- 0:00Store-only bounds checking intro
- 1:31Memory safety remains unsolved
- 2:55Partial bounds checking approaches
- 3:39Store-only bounds checking core
- 6:27Pointer vs object bounds checking
- 7:29How store-only checks work
- 8:11Vulnerability in store-only checks
- 9:35Threat model flaws
- 10:38Bypassing store-only checkers
- 11:42Intel MPX worst case
- 12:02Exploitation without invalid reads
- 13:47Exploitable patterns prevalence
- 15:11Debunking store-only argument
- 16:13Modern bounds checker trends
- 17:58Cryptographic immutability in checks
- 19:03Store-only plus crypto checks
- 19:44Data flow integrity alternative
- 20:25Summary and open questions
related talks
01h 03mBPF and Spectre: Mitigating transient execution attacks
41mA General Approach to Bypassing Many Kernel Protections and its Mitigation
01h 46mA little Introduction to Control Flow Integrity
34mGetting on the Same (Virtual Memory) Page: A Roundtable on Data-only Attack Mitigations
01h 34mA Little Introduction to Control Flow Integrity in C++
46mMeaningful Bounds Checking in the Linux Kernel
52mSecuring The Unseen: Vulnerability Research In Confidential Computing
01h 05mHow to Survive the Hardware Assisted Control-Flow Integrity Enforcement