Discussion about this post

User's avatar
lcamtuf's avatar

It's probably worth adding that the WH argument rests to a large extent on counting CVEs. Counting CVEs is deeply problematic for a number of reasons. For one, it reflects organizational practices more than anything else, with the totals skewed toward a handful of vendors - such as Chrome or the Linux kernel - that are more forthcoming than others about internal fuzzing and hardening work.

But more importantly, CVE counts have almost no bearing on the real world, in the sense that they don't correspond to the ease of attacking any specific software, the likelihood that such attacks will occur, or their relative importance. Attempts to count CVEs for other reasons - e.g., to "prove" that a particular browser or OS is more secure than another - have been derided many times before.

The one thing I probably should have expounded on is the secondary attack surface: for example, the ability to escalate to a higher privilege level after an initial compromise of a browser renderer. This is a very specialized concern, but it's true that the C/C++ attack surface for "second-step" attacks is larger than implied in my post. That said, it's generally better to keep the secondary attack surface tight; for example, seccomp-bpf is usually a more robust defense than a fully-exposed Linux kernel written in Rust could ever be.

Expand full comment
Ben's avatar

Strong agree. When Cyclone was blazing a trail in memory safe systems language design 20+ years ago, it seemed like an exciting step forward. But in addition to the mitigations you mentioned, sanitizers, fuzz testing and better idioms in C++ have all made it far more practical to develop pretty darn safe code in C/C++ than it was a generation ago.

Expand full comment
8 more comments...

No posts