[dpbriggs]

Look no further than the browser you're likely using: Google Chrome.

There's 91 code executions and 121 RCEs, details here: https://www.cvedetails.com/product/15031/Google-Chrome.html?...

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?

Nice hyperbole. Check the stats [1].

[0] https://analysis.chromium.org/p/chromium/coverage

[1] https://www.cvedetails.com/product/47/Linux-Linux-Kernel.htm...

[madmax96]

>Nice hyperbole

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].

[roca]

> 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.

[madmax96]

Or that the exploit is so difficult it is practically impossible to attack.

>but it’s just wrong

Who’s moving the goal posts now? The parent was talking about vulnerabilities, not bugs.

[roca]

> 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.