Memory Safety and the Future of Vulnerabilities

Presented at the Cal Poly Pomona SWIFT Tech Symposium 2025.

Transcript

1. Memory safety and the future of vulnerabilities A talk by Andrew Lilley Brinker Approved for Public Release; Distribution Unlimited. Public Release Case Number 251031. The author’s affiliation with The MITRE Corporation is provided for identification purposes only, and is not intended to convey or imply MITRE’s concurrence with, or support for, the positions, opinions, or viewpoints expressed by the author. ©2025 The MITRE Corporation. ALL RIGHTS RESERVED.
2. I’m Andrew Principal Cyber Security Engineer  MITRE Rustacean for 11 years I am not speaking for MITRE today.
3. What is memory safety?
4. What kinds of weaknesses? 1 buffer overflow 1. null pointer dereference 2. use after free 3. use of uninitialized memory 4. illegal free (of an already-freed pointer, or a non- malloced pointer) 5. Michael Hicks, “What is memory safety,” http://www.pl-enthusiast.net/2014/07/21/memory-safety/ 1.
5. Or, this bigger list  The Common Weakness Enumeration CWE Memory Safety category
6. Spatial Memory Safety Out-of-bounds accesses Reads or writes, under or over 1 Yoshua Wuyts, “What are temporal and spatial memory safety?” https://blog.yoshuawuyts.com/temporal-spatial-memory- safety/ 1.
7. Heartbleed was a spatial memory safety vulnerability
8. Why is that bad? Client: heartbeat “Hello” length 1,000 bytes Server: heartbeat “HellobfsfhgafSocial Security Number 123456789…”
9. But Wait, There’s More!  This is “Smashing the Stack for Fun and Profit”
10. Temporal Memory Safety Use after free Use of uninitialized memory Double-free
11. Memory safety is when these problems don’t happen Memory safe languages stop memory safety problems
12. What languages are memory safe?  From “The Case for Memory Safe Roadmaps” Published by CISA, NSA, FBI, ASD’s ACSC, CCCS, NCSCUK, NCSCNZ, CERTNZ
13. Which ones aren’t? C and C
15. Rust 1.0 was May 15, 2015 Also the day of my first date with my wife)
16. 9 years later…  The White House publishes this…
17. The govt. asked for input  CISA / ONCD / NSF / DARPA / OMB Request for Input RFI on open source software OSS security.
18. In the responses… Microsoft, Google, Cloudflare, GitHub, IBM, and many others recommend moving to memory safe languages.
19. The move to memory safe languages is happening What does this mean for vulnerabilities?
20. Let’s look at the CWE Top 25! In 2024 20% are memory safety related – 35% known-exploited are memory safety related –
21. We’ll always have… Bad authentication / authorization – Bad neutralization of user input – Resource exhaustion But what else? –
22. Micro- architectural vulnerabilities
23. Spectre and Meltdown Spectre: trick branch predictor into leaking data Meltdown: read memory faster than the privilege check, then recover data from cache
24. These affected every Intel processor from 1995 to 2018
25. The hits start coming and they don’t stop coming Spectre, Meltdown, Spectre-NG, SpectreRSB, Foreshadow, Zombieload, CROSStalk, Phantom, Zenbleed, Inception, Downfall
26. And it’s not just Intel!  That’s from this year! Turns out Apple CPUs since the M2 / A15 have a Load Address Predictor and Load Value Predictor. Oh no!
27. Problem: how to have fast processors that aren’t full of speculative execution vulnerabilities
28. Cryptographic vulnerabilities
29. Cryptography libraries are better than they used to be
30. But… Primitives being correct doesn’t mean a protocol is secure
31. We need post-quantum cryptography Harvest now, decrypt later
32. Problem: many existing protocols can’t easily adapt to post-quantum cryptography
33. Supply Chain Vulnerabilities
34. Code reuse is good!
35. But: xz-utils Last year we narrowly avoided the worst open source software supply chain attack in history.
36. Seriously, go read the story of this attack.  Russ Cox, co-creator of the Go programming language, has a great timeline
37. More commonly, we have stuff like this… Also: Typosquatting – Malicious contributions – Account takeovers – Token reuse –
38. Conclusions
39. Memory safety vulns won’t disappear But they will become less common
40. There’s still a lot to secure
41. Be Curious!
42. How to Reach Me Bluesky: LinkedIn: @alilleybrinker.com @alilleybrinker