6 ms·

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 w

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.

tester756 4y ago
Memory issues and JIT bugs mostly :) https://microsoftedge.github.io/edgevr/posts/Super-Duper-Secure-Mode/ 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-approach-to-more-secure-code/ 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-safety/ 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 4y 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.
  - winrid 4y ago
    There's also plenty of hand rolled assembly in there...
- gus_massa 4y 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?
  - greenthrow 4y ago
    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.
  - RadiozRadioz 4y ago
    I recommend switching Gmail to HTML mode[1]. I switched a few months ago, so much faster, never looked back. [1]: https://support.google.com/mail/answer/15049?hl=en https://support.google.com/mail/answer/15049?hl=en
    - dopa42365 4y ago
      Or an email client of your choice? I don't even remember when I last checked my emails on a website.
    - deleted 4y ago
      [deleted]
    - 4y ago
eska 4y 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.
pjmlp 4y 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_ope.html 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.
- mk89 4y ago
  Do you know why/if a sanitizer is not enough to catch these bugs at runtime (and during their automated tests)?
  - saagarjha 4y ago
    Google invests heavily in sanitizers. It funded the development of the ones that ship with LLVM.
    - mk89 4y ago
      Yes, I know. My question was more if or why a sanitizer doesn't help.
masklinn 4y 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 4y 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
  - rippercushions 4y ago
    Allowhats and denyhats? Or maybe defenderhats and exploiterhats.
  - gilrain 4y ago
    I also disapprove of the irrational behavior I imagine might exist, potentially.
  - dekhn 4y ago
    I think that stopped a few years ago when people realized it wasn't reasonable.
    - Gigachad 4y ago
      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.
dmitriid 4y 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 https://web-confluence.appspot.com/#!/confluence [2] https://www.openhub.net/p/chrome/analyses/latest/languages_summary https://www.openhub.net/p/chrome/analyses/latest/languages_s...
mike_hearn 4y 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/+/6b4af5d8208398839e90c7adc2da22c0288d6b47 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 4y 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

tester756 4y ago

Memory issues and JIT bugs mostly :) https://microsoftedge.github.io/edgevr/posts/Super-Duper-Secure-Mode/ 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-approach-to-more-secure-code/ 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-safety/ 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 4y 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.
- winrid 4y ago
  There's also plenty of hand rolled assembly in there...
gus_massa 4y 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?
- greenthrow 4y ago
  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.
- RadiozRadioz 4y ago
  I recommend switching Gmail to HTML mode[1]. I switched a few months ago, so much faster, never looked back. [1]: https://support.google.com/mail/answer/15049?hl=en https://support.google.com/mail/answer/15049?hl=en
  - dopa42365 4y ago
    Or an email client of your choice? I don't even remember when I last checked my emails on a website.
  - deleted 4y ago
    [deleted]
  - 4y ago

eska 4y 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.

pjmlp 4y 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_ope.html 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.

mk89 4y ago
Do you know why/if a sanitizer is not enough to catch these bugs at runtime (and during their automated tests)?
- saagarjha 4y ago
  Google invests heavily in sanitizers. It funded the development of the ones that ship with LLVM.
  - mk89 4y ago
    Yes, I know. My question was more if or why a sanitizer doesn't help.

masklinn 4y 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 4y 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
- rippercushions 4y ago
  Allowhats and denyhats? Or maybe defenderhats and exploiterhats.
- gilrain 4y ago
  I also disapprove of the irrational behavior I imagine might exist, potentially.
- dekhn 4y ago
  I think that stopped a few years ago when people realized it wasn't reasonable.
  - Gigachad 4y ago
    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.

dmitriid 4y 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 https://web-confluence.appspot.com/#!/confluence [2] https://www.openhub.net/p/chrome/analyses/latest/languages_summary https://www.openhub.net/p/chrome/analyses/latest/languages_s...

mike_hearn 4y 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/+/6b4af5d8208398839e90c7adc2da22c0288d6b47 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 4y 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