For the third time this year, Google’s Chrome browser has quietly received a security update with the dreaded words, “Google is aware that an exploit […] exists in the wild.

In this case, the bug is officially dubbed CVE-2022-1364: Type confusion in V8.

V8 is Google’s JavaScript engine, the same used by Edge and many other mainstream browsers.

The V8 engine is also used in node.jsa self-contained JavaScript programming ecosystem widely used today as a server application language.

How serious is this bug?

We can’t tell from Google’s downplayed warning, but about a month after the first zero-day patch of the year, the company released a pretty dramatic follow-up report.

In this case, Google wrote that the bugs discovered were attributed to two different North Korean cybercriminal groups, and that the attacks apparently spanned the media, IT, cryptocurrency and fintech sectors. .

We’re not aware of any follow-up reports for last month’s emergency patch – it’s possible, after all, that Google just hasn’t traced the second batch of attacks to their source yet. ..

… but, as we noticed last time, and the time before: patch now!

Why stay behind when you can now be ahead of the crooks?

(For tips on how to check and what version numbers to look for in Chrome and Edge, see our What to do? part below.)

Type Confusion Explained

“Type confusion” bugs are a class of memory mismanagement flaws where a block of memory that is supposed to be used by one type of computation is inadvertently consumed and trusted by a different algorithm.

For example, mixing a 64-bit unsigned integer and a 64-bit floating point number will usually mess up your calculation terribly, because the internal layouts of the two number formats are incompatible.

A 64-bit unsigned integer is just a string of bits that directly represents a number from 0 to 2⁶⁴-1.

But a double-precision float consists of three numeric parts packed into 64 bits, with one bit representing the sign, 11 bits representing the magnitude of the number (from super lowercase 2^-1022 at super-massif 2¹⁰²³plus 52 bits representing the fractional part of the number.

So the number 42 appears as the following binary strings when packed into 8-byte blocks of memory (we used hexadecimal, not binary, to save space):

42 decimal packed as 64-bit unsigned --> 0000 0000 0000 002A 
42 decimal packed as 64-bit double   --> 4045 0000 0000 0000

The double value is not treated as a simple bit string, but is broken down into binary as follows:

404      --> 1 sign bit = 0 (positive)
             11 exponent bits = 10000000100 (value 1028; subtract 1023 giving 5; exponent is 25 = 32)
50000... --> binary fraction = 0101000.... (add 1, giving binary 1.01010, or decimal 1.3125)

Multiply the fraction 1.3125 × 32 to get 42.0

What if you mix encodings?

If you mix the two encodings, you get the following bizarre results, turning the 64-bit integer version of 42 into a really tiny decimal fraction, and the floating-point version of 42.0 into an absurdly large integer:

0000 0000 0000 002A processed as a double float  --> 2.0750757125332 x 10-322
4045 0000 0000 0000 processed as 64-bit unsigned --> 4,631,107,791,820,423,168

As you can see, even confusing integers and floating point numbers can lead to dangerous miscalculations, especially if the code that misinterprets the raw data assumes that the value can be trusted because it has already been checked when the data was initially calculated and stored.

What if you mix in something much worse?

In real life, especially in complex software such as scripting engines, type confusion between two more complex types of memory blocks can have even more dramatic consequences.

For example, imagine that as an attacker you have a way to create an icon from a bitmap you provide, and your icon is compressed into a block of memory something like this:

integer value giving width of cursor icon
integer value giving height of cursor icon
string of width × height bytes denoting icon transparency

For a 16×16 pixel icon, assuming 8 bytes for each of the two integers, this gives you a way to encode an accurate pattern up to 8 + 8 + 256 = 272 bytes in a block of memory used by the application to represent an icon object.

As long as the app only interprets and uses this icon data to reconstruct and display your icon, and validates that the width and height are safe to use, you can’t do anything wrong (except, maybe be, to display a weird icon).

But now imagine that immediately after creating the icon memory buffer, you could trick the application into believing that the data it just stored was a completely different type of object, such as one structured as follows:

integer value giving number of iterations to try
integer value giving size of output to create
memory pointer to function called to generate each data value
memory pointer denoting where to output the generated data

This is of course an imaginary situation (it’s not representative of any known bug in the Chrome or JavaScript engine that we know of, now or in the past), but it helps you paint a mental picture of the dangerousness of this type of confusion. could be.

Instead of having the treacherous power to mix the numeric values ​​42 and 4.6 million million million, as we saw in the integer versus float confusion above, you would potentially have the power to “create “an innocent-looking icon that subsequently, and deliberately, misdirected the application’s execution.

You can not only configure things for the application to call unwanted code in the future (the generator function), but also to write whatever data you want (the generator output), in an amount of your choice (the number of iterations), at a memory location of your choice (via the output pointer).

What to do?

As always, make sure you have the latest version of Chrome.

Google has released two relevant security advisories: one for Windows, Mac and Linuxand a second, largely identical newsletter for android.

Your version of Chrome on all these platforms should now be Chrome 100.0.4896.127 (or later), published on 2022-04-14.

Google’s Play Store doesn’t give specific details for Android users, saying, generally noncommittally, that the “Current version varies by device”. (The most recent date given for an update, however, is listed as 2022-04-14.)

We notice that many unofficial Android download sites (no, we won’t recommend any; stick to Google Play if you can) already have version 100.0.4896.127 available, so we’re guessing that many devices, presumably including those of Google phones, therefore, already have the latest version downloaded or ready to be downloaded.

Microsoft Edge received an update on 2022-04-15; we don’t know if it includes this fix, but if you still want to get it, you are looking for Edge 100.0.1185.44.

If you haven’t updated yet, or are unsure, you can do this:

• Google Chrome. Three-dot menu (⋮) > To help > About Chromium.
• Microsoft Edge. Settings and more (…) > Help and feedback > About Microsoft Edge.
• Android. Open the play store app, click your account icon and check for app updates.

Do not be too long; Do it today!

---