Upgrade to Pro
— share decks privately, control downloads, hide ads and more …
Speaker Deck
Features
Speaker Deck
PRO
Sign in
Sign up for free
Search
Search
Memory Safety and the Future of Vulnerabilities
Search
Andrew Lilley Brinker
April 15, 2025
Programming
0
16
Memory Safety and the Future of Vulnerabilities
Presented at the Cal Poly Pomona SWIFT Tech Symposium 2025.
Andrew Lilley Brinker
April 15, 2025
Tweet
Share
More Decks by Andrew Lilley Brinker
See All by Andrew Lilley Brinker
Hello and Welcome: Documentation in the Rust Ecosystem
alilleybrinker
0
7
A Tale of Teaching Rust
alilleybrinker
0
7
Efficient Nimber Calculation in Dots and Boxes
alilleybrinker
0
96
Other Decks in Programming
See All in Programming
可変性を制する設計: 構造と振る舞いから考える概念モデリングとその実装
a_suenami
7
1k
リッチエディターを安全に開発・運用するために
unachang113
1
280
顧客の画像データをテラバイト単位で配信する 画像サーバを WebP にした際に起こった課題と その対応策 ~継続的な取り組みを添えて~
takutakahashi
4
1.4k
プロダクトという一杯を作る - プロダクトチームが味の責任を持つまでの煮込み奮闘記
hiliteeternal
0
290
Jakarta EE Meets AI
ivargrimstad
0
400
AI時代の『改訂新版 良いコード/悪いコードで学ぶ設計入門』 / ai-good-code-bad-code
minodriven
24
10k
No Install CMS戦略 〜 5年先を見据えたフロントエンド開発を考える / no_install_cms
rdlabo
0
380
リバースエンジニアリング新時代へ! GhidraとClaude DesktopをMCPで繋ぐ/findy202507
tkmru
4
1.4k
バイブコーディング超えてバイブデプロイ〜CloudflareMCPで実現する、未来のアプリケーションデリバリー〜
azukiazusa1
2
730
React 使いじゃなくても知っておきたい教養としての React
oukayuka
14
4k
[DevinMeetupTokyo2025] コード書かせないDevinの使い方
takumiyoshikawa
2
220
型で語るカタ
irof
1
860
Featured
See All Featured
Sharpening the Axe: The Primacy of Toolmaking
bcantrill
44
2.4k
Git: the NoSQL Database
bkeepers
PRO
431
65k
Code Reviewing Like a Champion
maltzj
524
40k
Facilitating Awesome Meetings
lara
54
6.5k
Reflections from 52 weeks, 52 projects
jeffersonlam
351
21k
Designing for Performance
lara
610
69k
Imperfection Machines: The Place of Print at Facebook
scottboms
267
13k
Raft: Consensus for Rubyists
vanstee
140
7k
10 Git Anti Patterns You Should be Aware of
lemiorhan
PRO
656
60k
Creating an realtime collaboration tool: Agile Flush - .NET Oxford
marcduiker
30
2.2k
Design and Strategy: How to Deal with People Who Don’t "Get" Design
morganepeng
130
19k
Typedesign – Prime Four
hannesfritz
42
2.7k
Transcript
Memory safety and the future of vulnerabilities A talk by
Andrew Lilley Brinker Approved for Public Release; Distribution Unlimited. Public Release Case Number 251031. 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.
I’m Andrew Principal Cyber Security Engineer MITRE Rustacean for
11 years I am not speaking for MITRE today.
What is memory safety?
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.
Or, this bigger list The Common Weakness Enumeration CWE
Memory Safety category
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.
Heartbleed was a spatial memory safety vulnerability
Why is that bad? Client: heartbeat “Hello” length 1,000 bytes
Server: heartbeat “HellobfsfhgafSocial Security Number 123456789…”
But Wait, There’s More! This is “Smashing the Stack
for Fun and Profit”
Temporal Memory Safety Use after free Use of uninitialized memory
Double-free
Memory safety is when these problems don’t happen Memory safe
languages stop memory safety problems
What languages are memory safe? From “The Case for
Memory Safe Roadmaps” Published by CISA, NSA, FBI, ASD’s ACSC, CCCS, NCSCUK, NCSCNZ, CERTNZ
Which ones aren’t? C and C
None
Rust 1.0 was May 15, 2015 Also the day of
my first date with my wife)
9 years later… The White House publishes this…
The govt. asked for input CISA / ONCD /
NSF / DARPA / OMB Request for Input RFI on open source software OSS security.
In the responses… Microsoft, Google, Cloudflare, GitHub, IBM, and many
others recommend moving to memory safe languages.
The move to memory safe languages is happening What does
this mean for vulnerabilities?
Let’s look at the CWE Top 25! In 2024 20%
are memory safety related – 35% known-exploited are memory safety related –
We’ll always have… Bad authentication / authorization – Bad neutralization
of user input – Resource exhaustion But what else? –
Micro- architectural vulnerabilities
Spectre and Meltdown Spectre: trick branch predictor into leaking data
Meltdown: read memory faster than the privilege check, then recover data from cache
These affected every Intel processor from 1995 to 2018
The hits start coming and they don’t stop coming Spectre,
Meltdown, Spectre-NG, SpectreRSB, Foreshadow, Zombieload, CROSStalk, Phantom, Zenbleed, Inception, Downfall
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!
Problem: how to have fast processors that aren’t full of
speculative execution vulnerabilities
Cryptographic vulnerabilities
Cryptography libraries are better than they used to be
But… Primitives being correct doesn’t mean a protocol is secure
We need post-quantum cryptography Harvest now, decrypt later
Problem: many existing protocols can’t easily adapt to post-quantum cryptography
Supply Chain Vulnerabilities
Code reuse is good!
But: xz-utils Last year we narrowly avoided the worst open
source software supply chain attack in history.
Seriously, go read the story of this attack. Russ
Cox, co-creator of the Go programming language, has a great timeline
More commonly, we have stuff like this… Also: Typosquatting –
Malicious contributions – Account takeovers – Token reuse –
Conclusions
Memory safety vulns won’t disappear But they will become less
common
There’s still a lot to secure
Be Curious!
How to Reach Me Bluesky: LinkedIn: @alilleybrinker.com @alilleybrinker