Smashing the Stack: Let’s Make It Less Fun And Unprofitable!
summary
Memory-unsafe bugs remain the dominant real-world cause of serious vulnerabilities: industry data show 60–70% of high-severity bugs trace to memory corruption, and Project Zero finds ~67% of exploited bugs are memory-related. Tooling like fuzzing and ASLR helps but doesn’t solve it; an incremental fix works—Android reduced 76%→35% of such bugs by rewriting components in Rust. Hardware prototypes like CHERI hardware halts out-of-bounds writes, while LLMs still fail (e.g., Gemini produced non-compiling Rust), so publishable memory safety roadmaps with dates, training plans and dependency strategies are the practical next step.
AI-written summary · about
chapters (18)
- 0:00Memory safety introduction
- 1:05Cybersecurity burden
- 3:13What is memory safety
- 5:23Memory safety data
- 7:53Traditional defenses limits
- 9:15Government efforts
- 12:07Memory safe languages
- 14:40Rewriting legacy code
- 15:43Rust as game changer
- 19:14Objections to memory safe
- 20:16AI for memory safety
- 23:06CHERI hardware
- 26:19Incremental migration
- 28:32Incentives and roadmaps
- 33:57Common criticisms
- 36:03Legacy code challenges
- 39:15Promote memory safety
- 42:01Q&A on dependencies
related talks
01h 01mMemory Safety: Rust vs. C
45mBuilding Safe and Secure Systems in Rust
57mFinding, Managing, Preventing Vulnerabilities: An Automotive Perspective
01h 00mIntroduction to memory exploitation
23mHow Do We Know That Weak Memory Matters?
44mUnsafe Rust
01h 01mSoftware Security
01h 16mClassic Vulnerabilities