[fay59]

That’s not really a “but” to the comment, which was that you need to find one bug and it’s game over. We’ve known for a long time that best practices aren’t enough to prevent memory corruption in large enough C++ code bases, so it’s likely a motivated attacker would eventually find something.

[DannyBee]

Sure - look i'm not gonna argue about C++ memory safety - i've funded and spent time trying to ensure we are funding figuring out how to get off of C++.

I just assume C++ code is unsafe, because it's really really hard to make it safe.

However, at the same time, the privilege escalation issues would have happened in any language - if you don't implement the check, you don't implement the check.

(and you could make it equally automatic in most languages)

[fay59]

What the missing access check protected was a stream of information that could defeat ASLR. If Zircon was written in a memory-safe language, that would have been the end of the issue. Logic bugs and missing access checks are still possible, but defeating them has fairly well definable consequences. Since Zircon isn’t written in a memory-safe language, the author was able to use that to fully compromise the kernel instead. I don’t mean that you can’t write bugs in memory-safe languages, but in the end the attacker still has to play by your rules. With a memory safety bug, attackers play by no one’s rules.

[ncmncm]

The code exploited was very, very far from any "best practice" in this decade, and probably the previous one.

[pjmlp]

Unfortunately still a common reality across many corporations.