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

https://www.bleepingcomputer.com/news/security/google-pushes-emergency-chrome-update-to-fix-8th-zero-day-in-2022/

by nixcraft • 4 years ago

138 47 4 years ago

Honest question: where do all of the new zero day vulnerabilities come from, new features/code? Just new bug detection techniques? I'd think over time entropy would get us to a point where there's hardly any vulnerabilities at all, but that's clearly not the case.

tester7562• 4 years ago

Memory issues and JIT bugs mostly :)

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

shp0ngle• 4 years ago

Chrome code size is giant, it's hard to "just" rewrite it to Rust.

There seem to be some experiments with adding Rust code slowly, but there seem to be some interop issues.

gus_massa• 4 years ago

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

Gmail takes forever to load in my machine. How much worse is the performance if I disable the JIT? x5?

edwnj• 4 years ago

A lot of criticisms on the way Mozilla was managed over the past few years, especially in terms of investments.. I think what they've done with rust hands down makes up for all it and more.

That language has the potential to really change the entire landscape.

fancl20• 4 years ago

How Rust's memory safety can help to solve JIT generating bug code?

BTW Chromium is testing rewriting critical parts in Rust (https://chromium.googlesource.com/chromium/src/+/refs/heads/...)

beanjuiceII• 4 years ago

i'd say that most of this code would have to live in unsafe rust

Grimburger• 4 years ago

you can literally turn off JIT with a few clicks

Am I the only one not able to see this for browsers other than Microsoft Edge?

Disabling JIT looks like cli flags only for Chrome/Brave/etc, which isn't activated when you've clicked on a link outside the browser or other methods for launching the default browser application, probably the most important times for security as it's often initiating login flows for apps or password resets.

Additionally it disables WASM, whereas Edge has alternate means to run WASM with JIT disabled.

Pretty disappointing to see from Google given the sheer extent of other in-browser settings flags.

Waterluvian• 4 years ago

What percentage of the total code in Chromium is the JIT?

(acknowledging that this is a very fuzzy question)

eska2• 4 years ago

The article mentions a heap buffer overflow in GPU, so it might be a driver issue. GPU drivers were traditionally not written with security in mind so there are a lot of potential bugs in there.

pjmlp3• 4 years ago

I don't know, C, C++, Objective-C, and everything else that might be copy-paste compatible with C semantics regarding strings, arrays, pointers and lack of bounds checking by default?

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.

mk894• 4 years ago

Do you know why/if a sanitizer is not enough to catch these bugs at runtime (and during their automated tests)?

masklinn2• 4 years ago

new features/code?

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.

xpressvideoz• 4 years ago

people (white or black hats)

I've just realized that these terms may also be subject to the crazy "every word is racism" movement these days. shudders

dmitriid• 4 years ago

Chrome pushes hundreds of new APIs every year [1]. On top of that modern browsers are huge unmaintainable beasts. Chrome is upwards of 25 million lines of code [2]

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...

mike_hearn• 4 years ago

It might be this one; fixed one day after the bug was discovered and the underlying bug is restricted:

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."

a1a106ed5• 4 years ago

Whenever you see 0days reported by someone from Threat Analysis Group it means that Google (TAG is a team within google) used some advanced detection technique to discover someone, usually a nationstate, "in-the-wild" exploiting this.

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

superjan• 4 years ago

https://nvd.nist.gov/vuln/detail/CVE-2022-4135

“Heap buffer overflow in GPU in Google Chrome prior to 107.0.5304.121 allowed a remote attacker who had compromised the renderer process to potentially perform a sandbox escape via a crafted HTML page. (Chromium security severity: High)”

beardyw• 4 years ago

If they are fixing it is it a zero-day? What does that mean in this context?

_kbh_• 4 years ago

If they are fixing it is it a zero-day? What does that mean in this context?

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.

SXX• 4 years ago

It would still be zero-day if Google knew that bug being actively exploited. Though in this particular case it's just bad writing.

muststopmyths• 4 years ago

I’m confused. If it’s a “heap buffer overflow in the GPU”, does this fix the chrome path to exploit and leave the driver for the manufacturer to patch ?

Or perhaps the bug is not actually “in the gpu “ ?

masklinn2• 4 years ago

It could be in a GPU kernel no?

eska2• 4 years ago

Oftentimes users of the GPU have to sanitize the data and commands sent to the GPU driver because it makes harsh assumptions about the inputs being legal. In that case the bug is on the application side because an unsafe API was used with arbitrary user input.

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

Related Stories