Google pushes emergency Chrome update to fix 8th zero-day in 2022

https://microsoftedge.github.io/edgevr/posts/Super-Duper-Sec...

>Looking at CVE (Common Vulnerabilities and Exposures) data after 2019 shows that roughly 45% of CVEs issued for V8 were related to the JIT engine. Moreover, we know that attackers weaponize and abuse these bugs as well; an analysis from Mozilla shows that over half of the “in the wild” Chrome exploits abused a JIT bug, as illustrated in the charts below. Note “Edge” below refers to the legacy version of Edge.

https://msrc-blog.microsoft.com/2019/07/16/a-proactive-appro...

>Figure 1: ~70% of the vulnerabilities Microsoft assigns a CVE each year continue to be memory safety issues

>C++ does have its virtues that make it attractive and in some cases essential: it is blisteringly fast, it has a small memory and disk footprint, it’s mature, it’s execution predictable, its platform applicably is almost unparalleled and you can use it without having to install additional components. If only the developers could have all the memory security guarantees of languages like .NET C# combined with all the efficiencies of C++. Maybe we can: One of the most promising newer systems programming languages that satisfy those requirements is the Rust programming language originally invented by Mozilla.

https://www.chromium.org/Home/chromium-security/memory-safet...

>The Chromium project finds that around 70% of our serious security bugs are memory safety problems. Our next major project is to prevent such bugs at source.

>Using safer languages anywhere applicable

>>Rust

______________

As you see you can literally turn off JIT with a few clicks and make your browser way safer.

Unfortunely you cannot force people to use Rust or other safe environments like .NET or Javas

Even if C++ and Objective-C are much better in that regard, as they offer bounds checked versions of those critical data stuctures, many devs just keep coding the good old ways, because performance trumps any attempt for security, until it eventually becomes a legal requirement to care for security.

> Many years later we asked our customers whether they wished us to provide an option to switch off these checks in the interests of efficiency on production runs. Unanimously, they urged us not to--they already knew how frequently subscript errors occur on production runs where failure to detect them could be disastrous. I note with fear and horror that even in 1980, language designers and users have not learned this lesson. In any respectable branch of engineering, failure to observe such elementary precautions would have long been against the law.

-- C.A.R Hoare on his Turing award speech in 1981.

> The combination of BASED and REFER leaves the compiler to do the error prone pointer arithmetic while having the same innate efficiency as the clumsy equivalent in C. Add to this that PL/1 (like most contemporary languages) included bounds checking and the result is significantly superior to C.

-- https://www.schneier.com/blog/archives/2007/09/the_multics_o...

Naturally, one can also argue that Google doesn't pay good enough to hire those mythical developers that never write code with security flaws.

Note that new code which is not intrinsically buggy can expose a latent bug in some other place which hadn't been found until then.

> Just new bug detection techniques?

Or people (white or black hats) giving a new area a try, from time to time there's a seminal paper or attack on a domain which hadn't been much looked at previously, and turns out to be flush with targets.

All of this compounds together: new features introduce new bugs, new features and maintenance expose old bugs, all of those changes suddenly make new bugs appear because no one know all the intricacies of this code etc.

[1] https://web-confluence.appspot.com/#!/confluence

[2] https://www.openhub.net/p/chrome/analyses/latest/languages_s...

https://chromium.googlesource.com/chromium/src.git/+/6b4af5d...

"Fix potential OOB problem with validating command decoder"

If that's truly the one then presumably the fix is rolling out now. From looking over the diff, the problem is likely to be quite old. Originally the rendering engine could talk directly to the GPU but when WebGL was introduced this was changed, supposedly because GPU drivers aren't hardened against malicious input and so WebGL - being a low level API - could have been used to get control over the renderer process from JavaScript by exploiting GL driver bugs.

Since then the renderer talks to a special libGL that serializes the GL command stream and writes it over a socket to the GPU process which then deserializes it, checking the stream for validity along the way before calling the "real" GL driver (which is probably ANGLE and thus another libGL emulation but that's by the by).

The bug in question is to do with insufficient validation of that command stream, specifically, the "level" parameter in a texture call wasn't being checked against the maximum mipmap level, but rather only against a different level limit.

Probably it means that JS using WebGL would have been able to craft an invalid texture and break into the GPU process this way. The GPU process is itself sandboxed but from there the malicious code could then e.g. see the contents of other tabs, and you're probably in a better position to break out of the sandbox entirely.

Although it's possible that the bug was introduced recently, on such a hot codepath and in such a fundamental function of the GPU command stream subsystem it seems much more likely that it was just never realized until now. That said, the GPU subsystem gets a LOT of commits so who knows.

Edit: notice this comment on the commit, so it suggests a design issue in old code that wasn't realized until recently: "this is a known vulnerability pattern that we only recently learned about, so we might not trust all of our validation code yet."

Reading their blog gives insight on how they find these. For example, for CVE-2021-30869 they discovered on a "watering-hole" website (i.e. some group in china hacked a hong kong protesting website and hosted an 0day on it to exploit protestors' devices). I'm guessing Google has methods to scrape the entire web looking for these browser exploits

They mention that they are aware that an exploit exists in the wild, so my guess is they counted it as fixing a 0day as they discovered it only after it was used.