Exploits, Tools & Data Recovery · Bug Classes & Mitigations · Lesson 1 of 5

Memory Safety Bugs

What memory corruption means in plain terms, and why it tops the bug charts.

Writing past the end of the form

In Mobile Malware you saw that the worst attacks often start with a single bug in code that handles untrusted data. This course looks at what those bugs are, and at the defenses that make them hard to use.

While a program runs, it keeps its data in memory, a huge row of numbered storage slots. When the program needs room for something, like a name or a picture, it reserves a block of slots of a certain size. A memory safety bug is a mistake where the program reads or writes memory it isn't supposed to touch. When the bug changes data it shouldn't, that's called memory corruption.

Two common kinds have everyday versions:

• Out-of-bounds write. Picture a paper form with ten boxes for your name. Someone writes a fourteen-letter name and keeps going, so the last four letters spill into the next field, which happens to be "amount to pay." The program reserved a block of a certain size, then wrote more data than fit, overwriting whatever sat next to it. Its cousin, the out-of-bounds read, is reading past the end of the form and picking up someone else's details.
• Use-after-free. Picture a gym locker. You hand back the key at the front desk, but you keep a copy. The gym assigns that locker to someone new, and later you open it with your old key and use what's inside, or leave things in it. In a program, a piece of code "frees" memory it's done with, then mistakenly keeps using it after that memory has been given to something else.

Why does this matter so much? Memory doesn't just hold names and pictures. It also holds the notes a program uses to decide what to do next. If an attacker can carefully control what gets spilled or what ends up in the reassigned locker, a memory safety bug can let an attacker run their own code inside the app or system that has the bug. The rest of this course is about how defenders stop that.

Why C and C++, and how common it is

Most of the code that sits closest to the hardware in phones, like operating system kernels, media decoders, Bluetooth and Wi-Fi software, and browser engines, is written in C and C++. These languages are fast and give programmers direct control over memory. The tradeoff is that they trust the programmer. They don't automatically check that every write fits in its box, or that a locker key is still valid. One missed check in millions of lines is enough.

Large companies have measured how often this goes wrong:

• Microsoft said in 2019, based on a talk by its engineer Matt Miller, that about 70% of the vulnerabilities it assigns a CVE each year are memory safety issues, and that the share had held steady for years.
• Chromium, the project behind Google Chrome, says around 70% of its high-severity security bugs are memory safety problems, based on 912 high or critical bugs since 2015. About half of those were use-after-free bugs.
• Android: Google reported that memory safety issues made up 76% of Android's vulnerabilities in 2019.

These bugs also tend to be the dangerous ones. In a December 2022 post, Google said that memory safety bugs were only about a third of Android's security bulletin vulnerabilities that year, yet they made up 86% of its critical-severity vulnerabilities and 89% of its remotely exploitable ones. Over the previous few years, they also accounted for 78% of confirmed in-the-wild exploited vulnerabilities on Android.

Google explained why. A bug like a permissions bypass usually grants access to one specific thing. Running code inside a process grants everything that process can reach, including a path to attack other parts of the system. That flexibility makes memory safety bugs useful for linking several bugs together, which is why most exploit chains Google has seen include at least one.

The good news is that this share is falling on Android, and module 4 explains why.