zlacker

First Microsoft, then two different teams at Google, and then Mozilla, and then someone else, all found that roughly 70% of security vulnerabilities reported in their products are due to memory unsafety issues. That roughly that number keeps coming up across all of the biggest companies in our industry lends it some weight.

Here's the first Microsoft one: https://www.zdnet.com/article/microsoft-70-percent-of-all-se...

And Chrome: https://www.zdnet.com/article/chrome-70-of-all-security-bugs...

>>stevek+(OP)
Yes, I'm well aware of what the data says, as well as what the data is measuring--CVEs and bug reports in well-known C/C++/Java projects.

But not too long ago, before SaaS, social media, etc, displaced phpBB, WordPress, and other open source platforms, things like SQL injection reigned supreme even in the reported data. Back then CVEs more closely represented the state of deployed, forward-facing software. But now the bulk of this software is proprietary, bespoke, and opaque--literally and to vulnerability data collection and analysis.

How many of the large state-sponsored penetrations (i.e. the ones we're most likely to hear about) used buffer overflows? Some, like Stuxnet, but they're considered exceptionally complex; and even in Stuxnet buffer overflows were just one of several different classes of exploits chained together.

Bad attackers are usually pursuing sensitive, confidential data. Access to most data is protected by often poorly written logic in otherwise memory-safe languages.

>>wahern+K2
My understanding was that while some of these are about CVEs and such, not all are. Like my understanding was the Microsoft numbers are from across all products, proprietary and open source.

>>wahern+K2
> How many of the large state-sponsored penetrations (i.e. the ones we're most likely to hear about) used buffer overflows?

It really depends on the target. If you’re attacking a website, then sure, you’re more likely to find vulnerability classes like XSS that can exist in memory-safe code. When you’re talking about client-side exploits like the ones used by NSO Group, though, almost all of them use memory corruption vulnerabilities of some sort. (That doesn’t only include buffer overflows; use-after-free vulnerabilities seem to be the most common ones these days.)

>>wahern+K2
The thing is, SQL injection and cross-site scripting are both trivial to defend against — at least compared to memory safety. It has a small surface area and most frameworks do help with it, or at least it is in their realm of possibility.

Preventing buffer overruns require language-level support.

>>wahern+K2
SQL Injection is a good lesson here. How is it mitigated effectively? By telling devs to write code carefully? No. It is mitigated by prepared statement libraries that are structurally resistant to SQL Injection. Similarly, "here are some static analysis tools - try your best to write safe C" is not a winning move.