Malcolm Owen
Google has issued its third urgent update for Chrome, one that patches another zero-day vulnerability in the highly-used desktop web browser.
Released on Thursday, the Stable Channel Update for Google Chrome's desktop variant brings the browser to version 100.0.4898.127, on macOS, Windows, and Linux. According to Google, the update will roll out over the coming days and weeks, but users may want to force the update earlier.
The update includes a pair of security fixes, including a "type confusion" vulnerability designated as CVE-2022-1364. The bug was reported by a member of the Google Threat Analysis Group on April 13, with Google rapidly bringing out a fix for it, writes The Register.
The bug in question is reckoned to be a high-severity zero-day, which is actively being used by attackers. Once performed, it can cause a browser to crash or trigger an error, which has the potential to allow arbitrary code to be executed.
The type of bug is similar to an issue that Google patched on March 26, which involved another "type confusion" weakness in Chrome's V8 JavaScript engine. Again, the latest exploit uses the same vector of the V8 JavaScript engine.
Google says it is "aware that an exploit for CVE-202201364 exists in the wild," a factor that contributed to the quick creation of a fix. However, rather than provide explicit details of the bug, Google says it is restricting access to that information until "a majority of users are updated" and therefore protected.
The update to the new version can be performed automatically for the user, though it can be manually performed in macOS by selecting "Chrome" in the main menu followed by "About Google Chrome." Once the update has been downloaded, click "Relaunch."
Charles Martin
Christine McKee
Wesley Hilliard
Andrew Orr
William Gallagher
Sponsored Content
7 Comments
I’ve settled on Safari as my primary browser and keep only one other browser, Firefox, just in case I encounter a website with Safari issues. But that hasn’t happened lately at all. Chrome is on my “Do not Use” list.
I'm running OS 12.13.1 on a Intel-powered Mac.
"About Google Chrome" reports the following:
Just wondering if the version number in this article is incorrect (XXXX.4098.XXX versus my 4896) or is the version number different for M1 Macs?
This is actually more than just a browser concern since it involves the V8 JavaScript engine which is the basis for Node.js, the underlying technology used in Electron apps, like Visual Studio Code. However, it sounds like they patched the more generic V8 issue earlier.
I wouldn’t point any fingers at Google here because the root cause of this specific issue is really tied to the “type inference” feature (or flaw depending on your viewpoint) of JavaScript. People who came into programming via C based languages and especially C++ with its “strong typing,” which is the polar opposite of type inference, often see languages like JavaScript as being a little too loosey-goosey or weak in the knees because they allow things that would be punished in C++ to be quietly ignored in these weaker languages, like JavaScript. It’s not like programmers can’t do lots of really stupid things in C/C++, but in most cases these strongly typed languages force the programmer to advertise their intention up-front, in the code (explicit casting) for everyone to see (and question) rather than quietly hiding what could be fatal flaws that arise when type inference goes wrong.
Why do we allow loosey-goosey things to exist in code? Because the emphasis for software development has shifted somewhat from correctness, infinitesimal detailed knowledge/attention to detail, and memory efficiency to productivity, ease of programming, and rapid application development. To avoid total chaos the newer “productivity” languages and development tools assume more responsibility for encapsulating the rote details inside the language implementation, and optimization techniques in the compilers and runtime engines manage the resulting inefficiencies and bloat as well as they can, but they too are never perfect because all of the safeguards are also developed by people who occasionally make mistakes, like what happened here. Of course these issues should be caught during testing, but that is another topic of discussion.