[paxys]

You are making the assumption that an engine with fewer optimizations that runs slower will be safer by default, but I fail to see the connection between the two.

[chlorion]

According to this analysis from Mozilla, over half of "in the wild" exploited vulnerabilities in chrome use bugs in the javascript JIT compiler.

https://docs.google.com/spreadsheets/d/1FslzTx4b7sKZK4BR-DpO...

https://docs.google.com/spreadsheets/d/1FslzTx4b7sKZK4BR-DpO...

(these links were found here https://microsoftedge.github.io/edgevr/posts/Super-Duper-Sec...)

So it does appear that there is a fairly heavy connection between the two things.

I am not an expert in JITs or JIT related security issues, but from my understanding, since JITs get to bypass the normal W^X memory restrictions, it makes it a really nice target for exploits and RCE.

[_Nat_]

For a simple example, [integer-overflow attacks](https://www.sciencedirect.com/topics/computer-science/intege... ) could be trivially prevented by always bounds-checking integers.

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.

[_Nat_]

For another example, [this story](https://www.bleepingcomputer.com/news/security/north-korean-... ) describes another zero-day that was allegedly found to have been exploited for weeks before discovery.

Apparently the timeline was:

????-??-??: The bug was discovered and exploited.

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.