Just three days after Chrome’s previous update, which fixed 24 security flaws that weren’t in the wild…
…Google programmers announced the release of Chrome 105.0.5195.102where the last of the four quadruplet numbers changes from 52 on Mac and Linux to 54 on Windows.
The release notes confirm, in the frustratingly cut and frustrating bug-reporting style of “indirect statement made in passive voice” that Google seems to have borrowed from Apple:
CVE-2022-3075: Insufficient data validation in Mojo. Reported by Anonymous on 2022-08-30 [...] Google is aware of reportsrts [sic] that an exploit for CVE-2022-3075 exists in the wild.
As always, our translation of security vulnerabilities written in this non-binding way is: “Scammers or spyware vendors discovered this vulnerability before us, figured out how to exploit it, and are already doing so.”
EoP or RCE?
We would love to be able to determine, since the bug is related to the mishandling of input data, if this bug leads to a concerning security outcome such as EoP, short for elevation of privilegeor whether it can be abused for a more disastrous outcome such as a full RCE, short for remote code execution.
EoP usually means scammers need malware to get started, so EoP bugs usually can’t be exploited to break in the first place.
They are still essential to fix, as a scammer who sneaks around your computer under the guise of a limited user such as GUEST will often bring an EoP exploit to “promote” himself so that he has root or sysadmin powers, aiming to transform what could otherwise be a modest risk on a single computer into a total compromise of your entire network.
RCE exploits, on the other hand, are commonly used either to gain a bridgehead inside a network to launch an attack, or to repeatedly hop from computer to computer once inside. interior, or both.
Again, the brevity of Google’s report means that while the bug report is High and not Criticalwe are going to invite you to deduce that we are talking about RCE here, and therefore to suppose a determined attacker could use this bug to plant malware from scratch.
Mojo and CPI
Mojoin case you were wondering, is a Google code library for something called IPC, short for interprocess communication.
Nowadays, for security reasons, browsers generally do not operate as a single, monolithic operating system process.
Basically, a process can be composed of several sonwhich are essentially “sub-processes” within the main process, by means of which a single program can quietly do two things at the same time, such as printing a document as you scroll through it, or running a backward spell check -plan.
Splitting a single-process application into threads is more convenient (meaning “it’s much faster and easier, but much less secure”) than splitting it into separate processes, because all the threads inside a process have access to the same piece of memory.
This means that threads can interact and share data much more easily, as they can simply draw directly from the same common pool of data, including checking current configuration settings, swapping memory addresses, sharing file descriptors , reusing cached images directly from RAM. , and much more.
On the other hand, sharing a large memory space means that a bug in a part of the program, like the thread that actively renders and displays your first browser tab, could trample or affect code that’s busy with other things. other things, like the threads managing the rest of the tabs you have open.
As a result, modern browsers typically split into many separate processes, for example so that each tab is managed in an independent process, thus preventing a tab runwaway from trivially retrieving data such as cookies and access tokens from other tabs related to completely different websites. .
Interprocess communication
This means you need a safe and reliable way to mix data between separate browser processes.
Instead of tab A and tab B simply consulting a common block of memory M in the main browser thread, the processes independent of the processes in tab A and tab B must receive their own copies of the data which they will need.
And that’s where it takes a well-appointed inter-process communication system or IPC.
All processes that brew data with each other through IPS must agree on how to properly construct that data for sending and how to safely deconstruct it at the other end.
The jargon term for this is serialization and deserializationbecause you’re taking chunks of data, possibly extracted from content already stored in many different areas of memory, and converting those chunks into a structured list of “here’s your own record of data items, types, and values things you need to know”.
Once serialized, the data can then be transmitted to another process – perhaps via a shared block of memory, or via an operating system level communication channel, via a network link, or even extracted into Morse code. so that anyone can retrieve it – so that the receiver can make sense of the data and decompress it independently, without needing to know anything about the current or future internal state of the sender’s process.
For example, if A sends B a 128-byte blob, would two 32-bit integers and two 64-bit floating-point numbers (4+4+8+8 = 24 bytes so far), followed by l single byte 0x67 ( 103 in decimal), followed by 103 bytes of ASCII text (4+4+8+8+1+103 = 128 bytes in total)?
Or is it a UTF-8 text message of exactly 120 bytes, padded with zeros if necessary to fill the space, followed by two 32-bit numbers that indicate the width and height of the window on the screen in which the ‘to display ?
When sender and receiver disagree
As you can imagine, misinterpreting the data you receive via IRC, or not verifying that it makes sense before relying on it, could have serious consequences.
In the first example, if the string length byte indicates a size greater than the amount of remaining data (e.g. 0xFF instead of 0x67), then blindly trusting that wrong size byte will cause you to read beyond from the end of the buffer.
In the second example, if process A forgets the width and height data and instead sends a full 128 bytes of UTF-8 text, then blindly “decoding” two 32-bit numbers at the end will produce incorrect values, maybe even dangerously. .
If you multiply these poorly coded numbers to determine how many bytes of storage to allocate to the on-screen window, you’re probably headed for memory mismanagement issues somewhere down the line.
Ideally, senders validate their IPC data outputs before transmitting them, and the receivers will be independently revalidate their IPC entries before consuming and using them, but [a] it doesn’t always happen and [b] even if that’s the case, you might still have problems if you have inconsistent validation procedures at either end.
In other words, “Insufficient data validation” IPC data being exchanged by cooperating processes is still a bug, and could end up being serious, as in this case.
What to do?
Patch early, patch often!
Check that you are up to date by clicking on Tthree points > To help > About Google Chromeor by accessing the special URL chrome://settings/help.
The version you are looking for is: 105.0.5195.102.
Google’s release notes also list an update to the Extended stable channelwhich you might be using if you’re on a work-provided computer – like the extended support release from Mozilla or ESR, it’s an official release that’s behind in features but keeps up with security patches, you so you don’t have to adopt new features just to get patched.
The extended stable release you want is: 104.0.5112.114.
Google also just announced an update to Chrome for iOS, available (as always) through the App Store.
It is not specified if the iOS version was affected by CVE-2022-3075, but the version you are looking for, in any case, is 105.0.5195.100.
(We assume that by iOS, Google means both iOS and iPadOS, which now ship in different variants of Apple’s underlying mobile operating system.)
Nothing in the release notes yet [2022-09-05T13:45Z] about Android – check Google Play to see if you’re up to date.
