Microsoft has lots of state-of-the-art dynamic and static analysis tooling for Windows. You don't hear much about it because a lot of it is closed source. E.g. here's some info about some of the static annotations they use in the kernel:
https://docs.microsoft.com/en-us/windows-hardware/drivers/de...
The links in the sidebar point to a lot of other stuff. If you look at the publications of MSR's software researchers, many of whom are very good, you will see lots of papers about finding bugs in Windows, some of which have been productized.
> In fact, a brand new project could probably reach 0 (or very close to it) memory bugs in C++ by following modern testing practices and using the variety of dynamic and static analyzers that exist today.
A bold claim to offer without evidence. Unfortunately even the best organizations have so far failed to achieve this.
> Microsoft has lots of state-of-the-art dynamic and static analysis tooling for Windows.
Right. If you look at the linked article, the Microsoft Engineer claimed 70% of security bugs in Microsoft products are caused by memory errors. Does Microsoft apply the same tools to all their products or only Windows? Do these tools even exist for other products?
> A bold claim to offer without evidence.
If one writes a new C++ program, tested with > 75% code coverage, tested with valgrind, the program passed coverity checks and clang static analysis, and they followed the best practices for hardening the host kernel, and told me that they still had an exploitable memory bug, I would be surprised. Notice that performing all those steps is still less effort than learning Rust and building the program in that. And you’d still have to harden your kernel and test anyway.
The evidence? NGINX and Linux is written in C. If the situation was so dire, why isn’t every computer in the world compromised right this second?
And the project has some of the best testing and practices in the world. Constant fuzzing, significant test coverage [0], no doubt there's memory sanitizers, etc.
It's increasing clear that large projects written in memory-unsafe languages will contain memory unsafety.
> The evidence? NGINX and Linux is written in C. If the situation was so dire, why isn’t every computer in the world compromised right this second?
Not hyperbole. Most of these bugs are never known to be exploited by attackers.
>Check the stats
In your first link, there was one memory corruption vulnerability in Chrome last year. If we're looking at RCEs, CVE-2019-5762 and CVE-2019-5756 appear to have the same root cause (a memory bug), and CVE-2018-6118, CVE-2018-6111, and CVE-2017-15401 (which is also the memory corruption vulnerability) are also memory bugs. So it looks like Chrome had ~4 serious memory vulnerabilities last year.
Don't have time to dig right now, but it appears similar observations hold for [1].
> Most of these bugs are never known to be exploited by attackers.
You have moved the goalposts. Of course there are lots of reasons why a bug might not be exploited by attackers, e.g. "the attackers exploited some other bug" or "no-one uses that software". That is not reassuring.
> In your first link, there was one memory corruption vulnerability in Chrome last year.
I don't know how you determined that, but it's just wrong.
https://www.cvedetails.com/vulnerability-list/vendor_id-1224...
Bugs 2, 3, 4, 8, 9, 10, 14 and 15 are obviously memory safety vulnerabilities. Many of the others probably are too, if you dig into them.
> Or that the exploit is so difficult it is practically impossible to attack.
"That bug is so difficult to exploit, it is practically impossible to use in an attack" does not have a good track record in the face of determined and ingenious attackers. Worse, once the attackers figure out how to overcome the difficulties, that knowledge spreads and is often packaged into kits that make it easier for the next bug.
> The parent was talking about vulnerabilities, not bugs.
I have no idea what you're talking about. Bugs 2, 3, 4, 8, 9, 10, 14 and 15 in that list are serious memory safety vulnerabilities that were found in Chrome last year, contrary to your assertion that Chrome only had four last year.
> If you look at the linked article, the Microsoft Engineer claimed 70% of security bugs in Microsoft products are caused by memory errors. Does Microsoft apply the same tools to all their products or only Windows? Do these tools even exist for other products?
They recently released an AddressSanitizer port for MSVC, and they've had Valgrind-like functionality for Windows userspace for over a decade (see https://www.usenix.org/legacy/events/vee06/full_papers/p154-...), but
I don't know of any public source describing what tools they use across their product range, so I don't know. They're well resourced, well motivated, and not stupid, so it would be surprising if they don't use the technology available.
I know that highly capable organizations, e.g. the Chrome and Firefox teams, do use state-of-the-art tools and practices in their browsers and get similar results to the Microsoft 70% number.
> I would be surprised
Check out Firefox and Chrome, for example, and be surprised.
> learning Rust
This isn't about Rust, but FWIW learning Rust doesn't seem so bad when you compare it to just the learning required to keep up with the ever-growing complexity of C++. (See e.g. Scott Meyers refusing to handle errata for his books because his C++ knowledge is obsolete after a few years out of the game.) Not to mention learning how to use and deploy in CI all the static and dynamic analysis tools you need to keep your C++ code safe(-ish).
> I know that highly capable organizations, e.g. the Chrome and Firefox teams, do use state-of-the-art tools and practices in their browsers and get similar results to the Microsoft 70% number.
Unfortunately, the threads grown too long and it’s starting to get difficult tracking referenced and arguments. The paper “Have things changed now? An empirical study of bug characteristics in modern open source software” specifically studies Firefox and finds no where near the 70% number (18%).
You're citing a paper from 2006. I'm not even going to read it.
As a former Mozilla distinguished engineer (left Mozilla in 2016), I assure you memory safety bugs are the majority of exploitable Firefox security bugs.
> In fact, a brand new project could probably reach 0 (or very close to it) memory bugs in C++ by following modern testing practices and using the variety of dynamic and static analyzers that exist today.
A bold claim to offer without evidence. Unfortunately even the best organizations have so far failed to achieve this.