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

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

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.

> 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 “ ?