Likewise, the current zero-day affecting Google's Chrome presumably could've been prevented with more robust type-checking on everything (assuming the bug is as-reported in the article). Such type-checking might be a bit slower, and possibly require a bit more RAM if objects weren't already carrying type-identifiers, but then no such zero-days, either.
A specific optimization that might be faulted for this zero-day in Google's Chrome, etc., might be describable as [type erasure](https://en.wikipedia.org/wiki/Type_erasure ). Presumably this was done because carrying type-identifiers (basically a tag that says what type an object is) requires more RAM (to store the type-identifiers) and more computation (to check that type-identifiers are correct/etc.). However, other optimizations may've been factors in this zero-day too.
2022-01-04: Earliest identified exploitation (according to the linked article).
2022-02-10: Google TAG discovered the vulnerability.
2022-02-14: Google Chrome was patched.
????-??-??: Hopefully most folks have updated by now, such that that particular attack isn't getting anyone anymore.
According to the article:
> Google’s Threat Analysis Group (TAG) attributed two campaigns exploiting the recently patched CVE-2022-0609 (described only as “use after free in Animation” at the moment) to two separate attacker groups backed by the North Korean government.
Generally, "use-after-free" vulnerabilities could be prevented by using more secure memory-management systems. To be clear: this is easy to do, programming-wise; presumably the vulnerability was able to occur because the software-design favored performance over security.
For another simple example, [buffer-overflow attacks](https://en.wikipedia.org/wiki/Buffer_overflow#Exploitation ) could be trivially prevented through the same sorts of checks.
A popular website for programmers, [StackOverflow](https://stackoverflow.com/ ), was named after this sort of thing.
Then there're memory-management errors that could be prevented through automated-memory-management (e.g., [use-after-free](https://en.wikipedia.org/wiki/Dangling_pointer#Security_hole... )), invalid-parameter exploits that could be prevented by parameter-validation, format-exploits that could be prevented by proper encoding (e.g., [SQL injection](https://en.wikipedia.org/wiki/SQL_injection )), etc..
Likewise, the current zero-day affecting Google's Chrome presumably could've been prevented with more robust type-checking on everything (assuming the bug is as-reported in the article). Such type-checking might be a bit slower, and possibly require a bit more RAM if objects weren't already carrying type-identifiers, but then no such zero-days, either.
A specific optimization that might be faulted for this zero-day in Google's Chrome, etc., might be describable as [type erasure](https://en.wikipedia.org/wiki/Type_erasure ). Presumably this was done because carrying type-identifiers (basically a tag that says what type an object is) requires more RAM (to store the type-identifiers) and more computation (to check that type-identifiers are correct/etc.). However, other optimizations may've been factors in this zero-day too.