Google Chrome for macOS gets another emergency zero-day fix

Posted:
in Mac Software
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."

Read on AppleInsider

Comments

  • Reply 1 of 7
    lkrupplkrupp Posts: 10,557member
    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.
    Japheywatto_cobra
  • Reply 2 of 7
    felix01felix01 Posts: 294member
    I'm running OS 12.13.1 on a Intel-powered Mac.

    "About Google Chrome" reports the following:

    Chrome is up to date
    Version 100.0.4896.127 (Official Build) (x86_64)

    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? 
    watto_cobra
  • Reply 3 of 7
    dewmedewme Posts: 5,423member
    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. 
    PetrolDaveFileMakerFellerwatto_cobra
  • Reply 4 of 7
    maximaramaximara Posts: 409member
    lkrupp said:
    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.
    Chrorme is so write happy to SSDs even on windows that any other browser is better:


    FileMakerFellerwatto_cobra
  • Reply 5 of 7
    maximara said:
    lkrupp said:
    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.
    Chrorme is so write happy to SSDs even on windows that any other browser is better:


    I wonder if Safari simply relies on the virtual memory system being efficient enough, and just keeps everything in RAM? The other browsers may be performing their own data caching due to a (probably informed) belief that it gives better speed - in which case, the data being written is explicitly measurable rather than being subsumed into the memory paging. I'm not sure this graph tells us anything meaningful.
    dewmewatto_cobra
  • Reply 6 of 7
    genovellegenovelle Posts: 1,481member
    maximara said:
    lkrupp said:
    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.
    Chrorme is so write happy to SSDs even on windows that any other browser is better:


    The problem with chrome is that it requires a server to be downloaded to your computer. That server is active and transmitting data even when chrome is not open. That is likely why it is writing so much more. I see this as a threat waiting to be exploited by the outside. In fact this exploit may be have been a channel google was using themselves. I find it interesting that they patched it within days of finding it, but have exploits they have left open for years. 
    watto_cobra
  • Reply 7 of 7
    maximaramaximara Posts: 409member
    maximara said:
    lkrupp said:
    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.
    Chrorme is so write happy to SSDs even on windows that any other browser is better:


    I wonder if Safari simply relies on the virtual memory system being efficient enough, and just keeps everything in RAM? The other browsers may be performing their own data caching due to a (probably informed) belief that it gives better speed - in which case, the data being written is explicitly measurable rather than being subsumed into the memory paging. I'm not sure this graph tells us anything meaningful.
    The graph shows all things being equal Chrome writes to the SSD more than any other browser.  Several Youtuve video have found that much of it is due to video.  Seems for whatever brain dead reason Chrome writes the video to the disk rather than keeping it in RAM like a intelligently written browser through people tired to blame Apple's VM despite as I pointed out Chrome is not kind to SSD on Windows machines either.
    edited April 2022 watto_cobra
Sign In or Register to comment.