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.
>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.
>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.
>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
No. Gmail is likely slow to load because it's loading, not because of code execution time. Disabling JIT doesn't make much difference for most users most od the time.
Protip: archive your inbox regulaely to improve gmail load time.
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.
Rust seems to provide memory safety built-in that is still possible in C++ with appropriate linters / static analysis (e.g., don't ever assign a `new` pointer to anything other than a unique one). I remember Google's codebase generally being good on this, but does Chromium not follow that?
My guess is yes and these are issues that would affect both languages equally, with Rust it just happens to be in an `unsafe` block.
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.
> 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.
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.
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.
My understanding though is that the ASAN would have done its job, had the test checked for the results. Quoting from the post:
> This fuzzer might have produced a SECKEYPublicKey that could have reached the vulnerable code, but as the result was never used to verify a signature, the bug could never be discovered.
If the result had been used, the ASAN would have kicked in, I guess, or?
Well, it is a lot of conditionals, and in any case binaries are seldom shipped with ASAN into production, so it would still be a lottery outcome if the fuzzer would have generated that specific use case.
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...)
it's not even line coverage. to be secure you need to be secure for every combination of branches. at 25 million lines of code, hitting every if/else combination would take longer than the lifetime of the universe.
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.
Did we? Renaming the master branch was clearly ridiculous but everything is still moving over to main. I think we are in for a never ending series of name changes.
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.
"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."
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
“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)”
> 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.
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 “ ?
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.
50 comments
[ 3.5 ms ] story [ 87.3 ms ] threadhttps://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
There seem to be some experiments with adding Rust code slowly, but there seem to be some interop issues.
Gmail takes forever to load in my machine. How much worse is the performance if I disable the JIT? x5?
Protip: archive your inbox regulaely to improve gmail load time.
[1]: https://support.google.com/mail/answer/15049?hl=en
That language has the potential to really change the entire landscape.
BTW Chromium is testing rewriting critical parts in Rust (https://chromium.googlesource.com/chromium/src/+/refs/heads/...)
Rust is an improvement to memory related issues
My guess is yes and these are issues that would affect both languages equally, with Rust it just happens to be in an `unsafe` block.
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.
(acknowledging that this is a very fuzzy question)
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.
https://googleprojectzero.blogspot.com/2021/12/this-shouldnt...
> This fuzzer might have produced a SECKEYPublicKey that could have reached the vulnerable code, but as the result was never used to verify a signature, the bug could never be discovered.
If the result had been used, the ASAN would have kicked in, I guess, or?
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.
I've just realized that these terms may also be subject to the crazy "every word is racism" movement these days. shudders
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
“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)”
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.
Or perhaps the bug is not actually “in the gpu “ ?