Double zero-day in Chrome and Edge – check your versions now!

If you’re a Google Chrome or Microsoft Edge browser fan, you’re probably getting updates automatically and you’re probably up to date already.

However…

…just in case you’ve missed any updates recently, we suggest you go and check right now, because the Chromium browser core, on which both Edge and Chrome are based, has patched not one but two zero-day remote code execution (RCE) bugs recently.

Google is keeping the details of these bugs quiet for the time being, presumably because they’re easy to exploit if you know exactly where to look.

After all, a needle is easy to find even in a giant haystack if someone tells you which bale it’s in before you start.

Browser-based security vulnerabilities that lead to remote code execution are always worth taking seriously, especially if they’re already known to, and in use by, cybercriminals.

And zero-days, by definition, are bugs that the Bad Guys found first, so that there were zero days on which you could have patched proactively.

RCE considered harmful

RCE means just what it says: someone outside your network, outside your household, outside your company – perhaps even on the other side of the world – can tell your device, “Run this program of my choosing, in the way I tell you to, without giving anything away to any users who are currently logged in.”

Usually, when you’re browsing and a remote website tries to foist potentially risky content on you, you will at least receive some sort of warning, such as a Do you want to download this file? dialog or a popup asking you Are you really sure (Yes/No)?

Sometimes, depending on the browser settings that you’ve chosen, or based on restrictions that have been applied for you by your IT sysadmins, you might even get a notification along the lines of, Sorry, that option/file/download isn't allowed.

But a browser RCE bug generally means that simply by looking at a web page, without clicking any buttons or seeing any warnings, you might provide attackerswith a security loophole through which they could trick your browser into running rogue program code without so much as a by-your-leave.

Common ways that this sort of security hole can be triggered include: booby-trapped HTML content; deliberately malconstructed JavaScript code; and malformed images or other multimedia files that the browser chokes on while trying to prepare the content for display.

For example, if an image appeared to need only a few kilobytes of memory, but later turned out to include megabytes of pixel data, you’d hope your browser would reliably detect this anomaly, and not try to stuff those megabytes of pixels into kilobytes of memory space.

That would cause what’s known as a buffer overflow, corrupting system memory in a way that a well-prepared attacker might be able to predict and exploit for harm.

Likewise, if JavaScript code arrived that told your browser, “Here’s a string representing a time and date that I want to you remember for later,” you’d hope that your browser would only ever allow that data to be treated as a block of text.

But if the JavaScript system could later be tricked into using that very same data block as if it were a memory address (in C or C++ terminology, a pointer) that denoted where the program should go next, a well-prepared attacker might be able to trick the browser into treating what arrived as harmless data as a remotely-supplied mini-program to be executed.

In the jargon, that’s known as shellcode, from time-honoured Unix terminology in which code refers to a sequence of program instructions, and shell is the general name for a control prompt where you can run a sequence of commands of your choice.

Imagine opening the Terminal app on a Mac, or a PowerShell prompt on Windows – that’s the sort of power that cybercriminal typically gets over you and your network if they’re able to use an RCE hole to pop a shell, as it’s jocularly called in the trade, on your device.

Worse still, a “popped” remote shell of this sort generally runs entirely in the background, invisible to anyone currently sitting in front of the computer, so there are few or no tell-tale signs that a rogue operator is poking around and exploiting your device behind your back.

A two-pack of zero-days

When we gave our RCE examples above, we didn’t choose booby-trapped image files and rogue JavaScript code by chance.

We highlighted those as examples because the two zero-day Chrome bugs fixed in the past few days are as follows:

• CVE-2023-2033: Type confusion in V8 in Google Chrome prior to 112.0.5615.121. A remote attacker could potentially exploit heap corruption via a crafted HTML page. Chromium security severity: High.
• CVE-2023-2136: Integer overflow in Skia in Google Chrome prior to 112.0.5615.137. A remote attacker who had compromised the renderer process could potentially perform a sandbox escape via a crafted HTML page. Chromium security severity: High.

In case you’re wondering, V8 is the name of Chromium’s open-source JavaScript engine, where JavaScript embedded into web pages gets processed.

And Skia is an open-source graphics library created by Google and used in Chromium to turn HTML commands and any embedded graphical content into the on-screen pixels that represent the visual form of the page. (The process of turning HTML into on-screen graphics is known in the jargon as rendering a page.)

A type confusion bug is one that works similarly to the text-treated-as-a-pointer example we presented above: a chunk of data that ought to be handled under one set of security rules inside the JavaScript process ends up being used in an unsafe way.

That’s a bit like getting a guest pass at the reception desk of a building, then finding that if you hold up the pass with your thumb in just the right place to obscure the “I am only a guest” label, you can trick the security guards inside the building into letting you go where you shouldn’t, and doing things you’re not supposed to.

And an integer overflow is where an arithmetic calculation goes awry because the numbers got too big, in the same sort of way that the time wraps round once or twice a day on your clock.

When you put an analog clock forward an hour from, say, 10-past-12 o’clock, the time wraps around to 10-past-1 o’clock, because the clock face is only marked from 1 to 12; similarly, when a digital clock gets to midnight, it flips back from 23:59 to 00:00, because it can’t count as far as 24.

What to do?

Wouldn’t it be handy if there were a single version number you could check for in every Chromium-based browser, and on every supported platform?

Sadly, there isn’t, so we’ve reported whay we found below.

At the time of writing [2023-04-24T16:00Z], the official laptop versions of Chrome seem to be: 112.0.5615.137 or 112.0.5615.138 for Windows, 112.0.5615.137 for Mac, and 112.0.5615.165 for Linux.

Anything at or later than those numbers will include patches for the two zero-days above.

Edge on your laptop should be 112.0.1722.58 or later.

Unfortunately, Chrome and Edge on Android (we just updated ours) still seem to be 112.0.5615.136 and 111.0.1661.59 respectively, so we can only advise you to keep your eye out for updates over the next few days.

Likewise, on iOS, our just-updated versions of Chrome and Edge show up respectively as 112.0.5615.70 and 112.0.1722.49, so we assume those versions will soon get updated to ensure both these zero-days are patched.

• Chrome on your laptop. Visiting the URL chrome://settings/help should show you the current version, then check for any missed updates, and attempt to get you up-to-date if you weren’t already.
• Chrome on iOS. The URL chrome://version will show your current version. Go to the App Store app and tap on your account picture at the top right to see if any updates are available that still need to be installed. You can use Update all to do them all at once, or update apps individually from the list below if you prefer.
• Chrome on Android. The URL chrome://version will show your current version. The three-dots menu should show an up-arrow if there is a Chrome update you don’t have yet. You will need to sign into your Google Play account to get the update.
• Edge on your laptop. Visiting the URL edge://settings/help should show you the current version, then check for any missed updates, and attempt to get you up-to-date if you weren’t already.
• Edge on iOS. The URL edge://version will show your current version. Go to the App Store app and tap on your account picture at the top right to see if any updates are available that still need to be installed. You can use Update all to do them all at once, or update apps individually if you prefer.
• Edge on Android. The URL edge://version will show your current version. Open the Google Play app and tap on your account blob at the top right. Go into the Manage apps & device screen to look for any pending updates. You can use Update all to do them all at once, or tap through into See details to update them individually.