Integer overflows, which require no mitigation other than getting a computer to count correctly, are extremely pernicious; they pop up even in systems that were deliberately coded defensively against them. There's an LP64 integer bug in qmail! And that's just for counting. Avoiding UAFs requires you to track and properly sequence every event in the lifecycle of an object --- and, in many C++ systems, also require you to count properly.
No, I don't think they're straightforward to avoid.
I think it seems straightforward to avoid memory lifecycle bugs because it's straightforward to avoid them under normal operating conditions. But attackers don't honor normal conditions; they deliberately force programs into states where events are happening in unexpected ordering and frequency.
I don't even know where to begin with the idea that it's acceptable to sacrifice a couple memory corruption vulnerabilities in the service of a faster browser.
> No, I don't think they're straightforward to avoid.
Fair enough, and you certainly have more experience on the topic than I do. Thanks for the explanation.
One quibble though, and maybe it was poor phrasing on my part:
> I don't even know where to begin with the idea that it's acceptable to sacrifice a couple memory corruption vulnerabilities in the service of a faster browser.
It's not really an either/or though, right? I mean, you can protect against some forms of attacks through a managed environment (though the environment itself adds its own attack surface). But you trade performance to get it. A managed language isn't going to solve all your problems, and it is going to mess with your performance in inconsistent and essentially intractable ways. I'm not saying "throw in a couple memory corruption vulnerabilities if it'll make it faster", I'm saying that you can fix memory corruption vulnerabilities. You can't fix inherently slow.
No, I don't think they're straightforward to avoid.
I think it seems straightforward to avoid memory lifecycle bugs because it's straightforward to avoid them under normal operating conditions. But attackers don't honor normal conditions; they deliberately force programs into states where events are happening in unexpected ordering and frequency.
I don't even know where to begin with the idea that it's acceptable to sacrifice a couple memory corruption vulnerabilities in the service of a faster browser.