BOOK THIS SPACE FOR AD
ARTICLE ADThis is the second pair of zero days that Google’s fixed this month, all four of which have been actively exploited in the wild.
Google has pushed out an emergency Chrome update to fix yet another pair of zero days – the second pair this month – that are being exploited in the wild.
This hoists this year’s total number of zero days found in the browser up to a dozen.
On Thursday evening, the web Goliath released the Chrome 94.0.4606.71 stable channel release for Windows, Mac and Linux to fix the two zero-days, which were included in an update with a total of four security fixes.
“Google is aware the exploits for CVE-2021-37975 and CVE-2021-37976 exist in the wild,” Google disclosed with the release of the browser fixes.
No Details for the Zero Days
Just as it did with the pair of zero days that were being exploited in the wild earlier this month, Google is keeping technical details close to the vest, at least until most users have had a chance to plug in the update. The company started pushing out Chrome 94.0.4606.71 to users worldwide in the Stable Desktop channel, and it should be available to all users within coming days.
“Access to bug details and links may be kept restricted until a majority of users are updated with a fix,” the company said in Thursday’s security update. “We will also retain restrictions if the bug exists in a third party library that other projects similarly depend on, but haven’t yet fixed.”
Here are details on the two zero-days:
CVE-2021-37976 is described as an “information leak in core” and was assigned a Medium severity level. It was discovered by Clément Lecigne from Google’s Threat Analysis Group (TAG) and reported on Tuesday of last week, Sept. 21. Credit for technical assistance also goes out to Sergei Glazunov and Mark Brand from Google Project Zero. CVE-2021-37975 is a user-after-free bug in the V8 JavaScript engine. Reported on Sunday, Sept. 26, by an anonymous contributor, it’s one of two flaws in Thursday’s update that were rated as high severity. V8 is Google’s open-source, high-performance JavaScript and WebAssembly engine for Chrome and Chromium-based browsers. It translates JavaScript code into a more efficient machine code instead of using an interpreter, which speeds up the web browser. Since this vulnerable component isn’t specific to Google Chrome, it’s a good bet that other browsers are affected by the bug as well.The second high-severity bug Google addressed on Thursday, CVE-2021-37974, is another use-after-free vulnerability: this time, in safe browsing.
The earlier pair of zero days Google addressed this month in a Sept. 13 update, CVE-2021-30632 and CVE-2021-30633, were likewise being actively exploited in the wild. The first was an out-of-bounds write in V8 JavaScript Engine, and the second was a use-after-free vulnerability in the IndexedDB API.
Use After Free
Use-after-free issues can result in any number of attack types, ranging from the corruption of valid data to the execution of arbitrary code. Writing for Threatpost’s InfoSec Insider series, Gurucul CEO Saryu Nayyar has described these flaws as among the year’s most dangerous software weaknesses.
As Nayyar tells it, use-after-free vulnerabilities entail memory manipulation: “When an application needs memory for a variable, it either programmatically allocates that memory, or the underlying platform (JVM or .NET Runtime),” she wrote earlier this month. “When the application is done with that memory, either it or the platform returns it to the free memory list.”
But if an attacker has managed to get the memory address, the actor “can gain access to the free memory list, and insert malicious software into free memory,” Nayyar continued. “The next time that memory is allocated, it is allocated with a payload that can cause harm. Further, the memory isn’t wiped clean when it is returned to the free memory list, enabling attackers to read the contents of that memory.”
She noted that some commercial debuggers can look into a running process and let programmers – or attackers – obtain information using memory locations. “While these types of debuggers are needed, any tool that lets attackers look into specific memory addresses to determine their contents has the potential to be used as a hacking tool,” Nayyar advised.
Check out our free upcoming live and on-demand webinar events – unique, dynamic discussions with cybersecurity experts and the Threatpost community.