Hacker News Board Hacker News, browsed like a classic message board
Live data from Hacker News

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

bleepingcomputer.com

Post reply on HN
Print view View original

31–40 of 51 posts

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

#31

Post by saagarjha »

fancl20 wrote: post #23
tester756 wrote: post #4

Earlier quoted context omitted.

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 bu…

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

It can’t, at least not directly. However, it can prevent bugs in the JIT runtime itself from being exploited.

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

#32

Post by adgjlsfhk1 »

mk89 wrote: post #25
pjmlp wrote: post #6

Earlier quoted context omitted.

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…

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

sanitizers don't work because they only check the paths that you actually run them on. vulnerabilities come from the weird combination of edge cases you didn't test.

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

#33

Post by beanjuiceII »

tester756 wrote: post #4
ClosedPistachio wrote: post #2

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.

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 bu…

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

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

#34

Post by marcosdumay »

beanjuiceII wrote: post #33
tester756 wrote: post #4

Earlier quoted context omitted.

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 bu…

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

Probably not. Code analysis and rewriting can all be done on safe rust. It's only data gathering and execution that needs unsafe, and those are the small and easy parts.

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

#35

Post by mike_hearn »

ClosedPistachio wrote: post #2

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.

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

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

#37

Post by winrid »

shp0ngle wrote: post #12
tester756 wrote: post #4

Earlier quoted context omitted.

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 bu…

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.

There's also plenty of hand rolled assembly in there...

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

#38

Post by mk89 »

saagarjha wrote: post #30
mk89 wrote: post #25

Earlier quoted context omitted.

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

Google invests heavily in sanitizers. It funded the development of the ones that ship with LLVM.

Yes, I know. My question was more if or why a sanitizer doesn't help.

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

#39

Post by mk89 »

adgjlsfhk1 wrote: post #32
mk89 wrote: post #25

Earlier quoted context omitted.

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

sanitizers don't work because they only check the paths that you actually run them on. vulnerabilities come from the weird combination of edge cases you didn't test.

Thanks. I thought so too, I just wanted to have some confirmation. It's not that they don't find issues, but it's more of a coverage issue then? (In which case I really understand, someone said it's 25 million lines of code...)

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

#40

Post by a1a106ed5 »

ClosedPistachio wrote: post #2

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.

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

Post reply on HN