Perpetual IT

QNAP, the makers of Networked Attached Storage (NAS) devices that are especially popular with home and small business users, has issued a warning about not-yet-patched bugs in the company’s products.

Home and small office NAS devices, which typically range in size from that of a small dictionary to that of a large encyclopedia, provide you with the ready-to-go convenience of cloud storage, but in the custodial comfort of your own network.

Loosely speaking, a NAS device is like an old-school file server that connects directly to your LAN, so it’s accessible and usable even if your internet connection is slow or broken.

Unlike an old-school file server, however, the operating system and file-serving software are preinstalled and preconfigured for you, as part of the device, so it Just Works.

No need to learn how to install Linux and Samba, or to wrangle with Windows Server licences, or to specify and build a server of your own and administer it.

NAS boxes typically come with everything you need (or with disk slots into which you add your own commodity disk drives of a suitable capacity), so you need to do little more than plug a power lead into the NAS, and hook up a network cable from the NAS to your router.

No need to buy a USB drive for every laptop and desktop you own, because the NAS can be shared, and used simultaneously, by all the devices on your LAN.

Configuring and managing the NAS can be done from any computer on your network, using a web browser to talk to a dedicated web server that’s ready and waiting on the NAS itself.

Convenience versus cybersecurity

Of course, the easy-to-use and ready-to-go nature of NAS devices comes with its own challenges:

• What if your NAS device ends up accessible from the internet? Even on your LAN, there’s a risk that malware on one internal device could harm data shared by all your devices, but a NAS box that’s visible from the internet is at permanent risk from potential attackers all over the world.
• What if the operating system software on the NAS has security holes? Many NAS boxes are based on a distribution of Linux that’s specific not only to the vendor but often also to the specific device. You may be unable to install updates yourself even if you are able to figure out which patches are needed, so you have to rely on the vendor for updates.
• What if the NAS web server sofware has security bugs? You don’t get to choose which web server, or which version, is used for configuring and managing the device. Once again, you typically need to rely on the vendor for security updates.

QNAP inherits bugs from Apache

QNAP’s devices generally use httpd, the popular Apache HTTP Server Project, running on a customised distro of Linux.

(Apache is the name of a software foundation that looks after a web server project amongst hundreds of others; although many people use “Apache” as shorthand for the web server, we recommend you don’t, because it’s confusing, rather like referring to Windows as “Microsoft” or to Java as “Oracle”.)

Just over a month ago, Apache released version 2.4.53 of its HTTP Server, fixing several CVE-tagged bugs, including at least two that could lead to crashes or even remote code execution (RCE).

Unfortunately, QNAP hasn’t yet pushed out the HTTP Server 2.4.53 update to its own devices, although it is now warning that two of the bugs that were fixed, CVE-2022-22721 and CVE-2022-23943, do affect some of its products.

Fortunately, exploiting those bugs relies on features in the HTTP Server code that are not enabled by default on QNAP devices, and that you can easily turn off temporarily if you have enabled them.

What to do?

The bugs and their workarounds are:

• CVE-2022-22721. A web client sending in a supersized HTTP request could cause a buffer overflow, thus provoking a server crash or even leading to an exploitable code execution hole. Check that the HTTP Server configuration setting LimitXMLRequestBody is set to 1MByte (the default) or below.
• CVE-2022-23943. If you have turned on the Apache HTTP Server mod_sed extension, which allows you to set up incoming and outgoing content filtering rules, you may be vulnerable to memory mismangement bugs if extrasupersized HTTP requests (bigger than 2Gbyte!) are received. We’re not sure why you would need to turn mod_sed on, but QNAP seems to think there may be customers who are using this feature. Check that mod_sed is not enabled. (The name mod_sed is shorthand for stream editing module, meaning that it can apply text editing rules to requests as they arrive, or to replies just before they’re sent out.)

QNAP says it intends to patch its devices, promising that it “will release security updates as soon as possible”, although we don’t want to guess how soon that will be, given that Apache itself made the patches publicly available just over five weeks ago.

You can keep your eye out for QNAP updates via the company’s decently laid-out Security Advisories page.

While you’re about it, remember that it’s very unlikely that you want a NAS of your own to be accessible from the internet side of your router, because that would leave it directly exposed to automated scanning, discovery and probing by cybercriminals.

Therefore we recommend the following precautions, too:

• Don’t open your network servers up to the internet unless you really mean to. QNAP has advice on how to prevent your NAS device from receiving connections from the public internet by mistake, thus preventing your device from being accessed or even discovered in the first place. Perform a similar check for all the devices on your network, just in case you have other private devices that can inadvertently be “tickled” from the internet.
• Don’t use Universal Plug-and-Play (UPnP). UPnP sounds very useful, because it’s designed to allow routers to reconfigure themselves automatically to make setting up new devices easier. But it comes with enormous risks, namely that your router might inadvertently make some new devices visible through the router, thus opening them up unexpectedly to untrusted users on the internet. Explicitly disable UPnP on every device that supports it, including on your router itself. If you have a router with UPnP that won’t let you turn it off, get a new router.

---

LISTEN NOW

• [00’24”] Fun Fact. Do you know your Adam Osborne from your John Osbourne?
• [01’12”] Another 0-day in Chrome.
• [05’03”] How not to choose a cybersecurity holiday destination.
• [07’37”] This Week in Tech History. The Osbo(u)rne Effect.
• [09’35”] Cryptododginess that might actually be legal.
• [20’01”] Oh! No! Old times – the Zilog Z80 versus the Mostek 6502.

With Doug Aamoth and Paul Ducklin.

Intro and outro music by Edith Mudge.

You can listen to us on Soundcloud, Apple Podcasts, Google Podcasts, Spotify, Stitcher and anywhere that good podcasts are found. Or just drop the URL of our RSS feed into your favourite podcatcher.

---

Oracle’s latest quarterly security updates just arrived.

Unlike other software behemoths such as Microsoft, Adobe and Google, who produce official security updates once a month, thus following a schedule that is both regular and frequent, Oracle has historically and resolutely stuck to just four scheduled updates a year.

Even Apple, which notoriously ships all its security updates “when they are ready”, and therefore has no pre-announced calendar that allows you to predict and plan your non-urgent patches, rarely goes much more than a month these days without delivering patches for known security holes.

So, as you can imagine, given Oracle’s huge product portfolio and its comparatively infrequent updates, when patches come, they typically come in large numbers.

This quarter’s updates are no exception, with 174 different products on the “patches available” list, from Engineered Systems Utilities, through Oracle Blockchain Platform and Oracle Secure Backup, all the way to Primavera Verifier.

Included in the security fixes listed for those 174 products are 401 distinct CVE-numbered bugs, of which well over half have CVE date tags of 2021 and earlier, with some going all the way back to 2017.

(For all that Oracle’s infrequent updates lead to huge patch lists, the company’s top-level Critical Patch Update Advisory is well-organised, and Oracle’s so-called “risk matrices” – the chief bugs for each product – are easy to find.)

In this article, however, we’re focusing on the bugs in Oracle’s Java product, of which seven made the official risk matrix on account of being remotely exploitable without authentication – in other words, they’re bugs that could be exploited from outside your network by someone who hasn’t yet logged in, or who doesn’t have a login in the first place.

Note that remotely exploitable doesn’t mean all these bugs lead directly to remote code execution, or RCE, where an outsider could literally implant and run any code they liked, merely that the bugs can be “reached” and abused by attackers who don’t yet have a formal foothold inside your network.

Psychic signatures

In fact, we’re focusing on just one of those Java bugs, officially known as CVE-2022-21449, but jokingly dubbed the Psychic Signatures in Java bug by researcher Neil Madden, who uncovered it and disclosed it responsibly to Oracle in November 2021.

Madden’s remark about “psychic signatures” is a joke derived from the long-running cult British sci-fi show Doctor Who, famous amongst its fans for Time Lords, Daleks, the TARDIS, Sonic Screwdrivers…

…and Psychic Paper.

Psychic Paper, according to Doctor Who fan site Tardis Data Core, is a blank sheet of paper or card made from the psychic trees of the planet Boda, which retain their psychic properties even after death (we’re merely reporting this, so please don’t complain if these details are considered imprecise or disputed in the Whovian canon), and can therefore be turned into blank pages that induce the “reader” to see precisely what they’re told is printed on them.

As you can imagine, ID cards made of psychic paper make a very convenient plot apparatus for Doctor Who to bamboozle security guards and bypass security checkpoints.

Madden’s bug nickname is therefore wittily chosen, given that the bug he discovered allows an attacker to bypass a Java Elliptic Curve signature check simply by presenting a memory buffer filled entirely with zeros.

You read that correctly: either you can generate a valid digital signature by dutifully applying the necessary private key to the calculation, or you can send across a bunch of zeros instead.

Computing ECC signatures

When submitting a digital signature based on Elliptic Curve cryptgraphy, you’re supposed to be proving to the recipient that you have access to the private key that corresponds to the public key that they’ll use to verify the signature at your end.

In simple terms, you take a fixed-length hash (e.g. SHA-256) of the data you want to authenticate, such as an email message or a software update, sign that hash with your private key, and submit the hash and the signature.

The recipient uses the matching public key to verify the hash, and then uses the hash to verify the message (which can therefore be arbitrarily long).

Because your private key can’t be worked out backwards from the corresponding public key, your public key can, quite literally, be made public, and attested to match your private key in numerous ways.

In other words, you can’t present a digital signature that will pass muster unless you have access to the relevant private key, so if the recipient assumes you have looked after your private key with the care it deserves, this sort of signature check provides a vital level of verification in today’s online exchanges of code and data.

But, as Madden discovered, a totally blank “psychic signature”, if presented to Java’s Elliptic Curve verification code, would be flagged as valid when “verified” against any public key.

In other words, an attacker would need either to hack into your network and steal your private keys in order to masquerade as you…

…or simply to present a blank signature to pass muster every time!

Although Elliptic Curve cryptography (ECC) is not the only type of public-key cryptosystem that can be used for digital signatures (other systems include RSA and Edwards Curves), it’s currently one of the most commonly used signature algorithms.

That’s because ECC keys and signatures are not only very widely supported these days, but also much more compact than their RSA equivalents, making them smaller, faster and easier to send and use across slow networks and in low-powered computing devices.

The problem with zero

The bug was caused by the fact that ECC signature calculations involve a pseudo-random number K that’s used to derive two further numbers, imaginatively referred to in the literature as R and S, like this:

S1. Select a cryptographically sound random integer K between 1 and N-1 inclusive.
S2. Compute R from K using Elliptic Curve multiplication.
S3. In the unlikely event that R is zero, go back to step 1 and start over.
S4. Compute S from K, R, the hash to be signed, and the private key.
S5. In the unlikely event that S is zero, go back to step 1 and start over.

The two numbers R and S together make up the signature, and it’s vital that neither of them be zero, or else the verification algorithm will always succeed, even if the data has been tampered with.

For that reason, the verification process requires its own up-front check to ensure that the signer didn’t skip step 3 or 5 above:

V1. If R is zero, the signer blundered. The signature cannot be verified. Reject it.
V2. If S is zero, the signer blundered. The signature cannot be verified. Reject it.

According to Madden, these vital preliminary checks were accidentally omitted back in the era of Java 15, when the C++ cryptographic code in the official Java runtime was rewritten in Java itself.

How dangerous is the bug?

As Madden pessimistically points out:

Although I’m sure that this rewrite has benefits in terms of memory safety and maintainability, it appears that experienced cryptographic engineers have not been involved in the implementation. The original C++ implementation is not vulnerable to these bugs, but the rewrite was. Neither implementation appears to have very good test coverage, and even the most cursory reading of the [Elliptic Curve Digital Signature Algorithm specification] would surely suggest testing that invalid R and S values are rejected. I am not at all confident that other bugs aren’t lurking in this code.

Note that the bug doesn’t depend on using a private key at all, or on finding a random number K in the signing process that actually does lead to R or S being zero for any input values involved.

All that’s needed is for the fake “signer” to pretend that R and S came out as zero by sending in an all-zero signature.

Madden himself, understandably, expressed surprise in his report that the official CVSS (Common Vulnerability Scoring System) “danger value” listed by Oracle came out at 7.5/10.

He suggests, as well he might, being the discoverer of this bug and thus our official saviour against it, that CVE-2022-21449 ought to have a danger asssessment at the maximum level of 10/10, meaning, “As critical as it gets; patch without delay.”

Typically, you’d expect a 10/10 security hole to be some sort of remote code execution flaw, perhaps even one considered wormable, meaning that it could be exploited not only to implant malware on your computer directly, but also to replicate that malware infection automatically and rapidly from your computer to any other vulnerable device accessible from it.

But Madden argues that a digital signature bypass like this one should be given a top-level bug ranking simply because so much is at stake when cryptographic checks can be sidestepped so easily.

After all, this bug doesn’t just affect Java servers that directly interact with client software connecting over the internet, so it’s not enough just to worry about internet-facing servers on your network that might get fooled by network traffic from attackers.

Any device that consumes digitally-signed data inside your network could be at risk.

A news service that relies on signatures to verify the source of submissions it’s sent; a product using digital signatures to verify the updates it just downloaded before installing them; or a logging system relying on signatures to ensure the integrity of the forensic records it’s maintaining…

…any of these, if coded in Java, could be at risk of being tricked into trusting and relying on vital content that it shouldn’t.

Remember that, unlike the infamous Log4Shell bug in late 2021, which affected many Java apps that happened to include the Log4J code, this Psychic Signature flaw is part of the Java runtime itself, so it potentially affects any Java app you have, whether it’s one of your own or comes from a third party.

What to do?

Update your version of Java as soon as you can!

The most recent Java versions are Java 17 (Long Term Support) and Java 18, which get updated to 17.0.3 and 18.0.1 respectively.

Older but still-supported versions that have also been patched are Java 7, Java 8 and Java 11, which get updated to version 7u341, version 8u331 and 11.0.15 respectively.

Remember that it’s possible to have multiple Java versions installed at the same time, in the form of the Java Development Kit (JDK) or the Java Runtime Environment (JRE).

You can check for available Java versions on your computer by searching for program files called java (or java.exe on Windows).

You can check what version each Java executable represents by running the command java -version.

SEARCHING FOR JAVA VERSIONS ON LINUX

### We found two different Java runtimes. One we'd installed directly;
### the other was part of the Arduino development project $ find . -name java -type f -executable ./Tools/arduino-1.8.12/java/bin/java
./Tools/jdk-18.0.1/bin/java
$ ### The Arduino-supplied Java will need updating via the ### Arduino app... $ ./Tools/arduino-1.8.12/java/bin/java -version
java version "1.8.0_191"
Java(TM) SE Runtime Environment (build 1.8.0_191-b12)
Java HotSpot(TM) 64-Bit Server VM (build 25.191-b12, mixed mode)
$ ### We updated our self-installed JDK directly from Oracle's
### https://www.oracle.com/java/technologies/downloads/ $ ./Tools/jdk-18.0.1/bin/java -version
java version "18.0.1" 2022-04-19
Java(TM) SE Runtime Environment (build 18.0.1+10-24)
Java HotSpot(TM) 64-Bit Server VM (build 18.0.1+10-24, mixed mode, sharing)
$ 

---

Back when the Bitcoin protocol was invented, the idea was to build a simple global payment system that wasn’t (and couldn’t be) controlled by any central broker.

In other words, you wouldn’t need to apply to a private company for a credit card, or to get permission from a regulator to send cash abroad, or to risk having incoming payments confiscated by a corrupt bank or central government, or to negotiate a series of complex exchange rates determined by other people, or to wait for the companies at each end of the transaction to decide that it was time to let it go through.

You could simply and directly trade online with someone else who decided that the bicoinage you were offering was somehow worth what they were giving you in return.

For better or worse, however, cryptocurrency networks such as Bitcoin have largely devolved into investment schemes instead of payment systems.

People tend to trade in Bitcoin, as they might in stocks and shares, rather than trading with it, as they would with cash, a credit card, or (in the olden days) a chequebook.

De-Fi to the rescue

So, a new wave of cryptocurrency systems dubbed De-Fi, short for decentralised finance, has arisen to fill that transactional void.

De-Fi systems don’t just aim to provide an algorithmic basis for digital currency, but instead to provide a fully-fleged alternative to the old-school, tightly regulated world of commercial banking.

Instead of depositing your funds with a licensed and regulated bank, and then trading with those funds by choosing from a carefully curated list of transaction types, De-Fi systems let you invest your money with them, in return for access to a “smart contract” system that allows you trade automatically with other users of the system in a way to suit yourself.

In very simple terms: you write your financial contracts as a chunk of computer code, and the De-Fi system processes it to handle and disburse your income as you choose.

If you wanted, for example, you could code a smart contract that waited for a payment from X, then automatically divvied up the funds between you and two friends in the ratio 6:5:4, unless the money arrived after a certain date, in which case the ratio would be 7:6:2. (You might want to offer the third recipient an automated incentive for helping you to secure early payment.)

By using distributed ledgers known as a blockchains, a sort of community-operated bookkeeping venture where transactions are agreed and recorded by consensus, De-Fi services don’t need to be managed by a traditional organisation such as a government’s central bank or a global payment card behemoth.

What could possibly go wrong?

Unfortunately, as we’ve written on Naked Security several times before, there’s quite a lot that can go wrong when you entrust your hard-earned income to a decentralised and largely unregulated operator.

What if the De-Fi service you choose is actually just a bunch of smoke and mirrors, and the founders of the “business” intended all along simply to run off with your “investments”? What if the founders are incompetent? What if the hastily constructed websites on which the business is based are full of cybersecurity holes?

What if the underlying cryptographic protocols themselves, on which the De-Fi company’s smart contracts are based, contain exploitable loopholes?

This last problem is what seems to have sunk the De-Fi company Beanstalk over the Easter weekend, where a scammer was apparently able to pull off a transaction sequence that went something like this:

1. Propose an “emergency transaction” that included paying funds to the scammer, under the guise of donating $250,000 to a Ukraine relief appeal. (This special transaction would require a two-thirds majority vote by the community, based on the collateral held by each voter. As you’d imagine, this sort of proposal would be unlikely to get voted through by anyone except the scammy proposer, whom you wouldn’t expect be able to come up with the massive financial collateral needed to vote it through.)

2. Wait long enough for voting on the “emergency transaction” to be activated.

3a. Borrow close to $100m in cryptocurrency from elsewhere in order to achieve the supermajority necessary to outvote everyone else.
3b. Approve the “emergency transaction” using the suddenly-acquired supermajority powers, transferring everything from Beanstalk to scammer.
3c. Instantly repay the absurdly-sized loan used to take control of the voting process.

4. Push the bulk of the remaining cryptomoney through a coin-tumbling service and keep it.

Beanstalk, according to its own blog, has thereby lost about $76 million of other people’s money, just like that.

Obviously, given that hindsight gives you the benefit of 6/6 vision, the core of the the problem here is that the protocol permitted the processes listed above as 3a, 3b and 3c to be conducted as if they were a single transaction, thus allowing what the De-Fi sector refers to as a flash loan (one that’s borrowed and repaid in one go, as part of an indivisible operation) to be used to acquire momentary but total power over the cryptocurrency service.

We suspect that most readers will agree that this sidestepped the spirit, if not the letter, of the supermajority provision in the “emergency transaction” process that Beanstalk had put in place.

(Traditional banks typically use well-known protocols for “emergency” operations, such as opening vaults, that make it physically as well as technically difficult for one individual to act in place of several, specifically to make it difficult for one person to use sneaky operational shortcuts to pull off a megaheist without getting detected in time, and stopped.)

Was it even a crime?

Nevertheless, as some observers have noted, the scammer in this case might not have broken any laws, depending on how you view legalistic phrases such as “unauthorised access”.

Beanstalk’s cryptocurrency token BEAN prided itself on being what’s known as a stablecoin, meaning that the system varied the way it rewarded buying into and cashing out of the service in order to maintain a real-world value of about $1, thus avoiding the inherent fluctuations that effectively turned Bitcoin from a trading currency into an investment service.

Sadly, despite managing quite well to maintain that stable $1 value point recently, BEAN tokens – those that are left with regular account holders, anyway – are now trading at just a few cents, according to Coingecko:

What to do?

An early reponse on social media by an alleged project spokeperson known as Publius expressed the desperation that everyone other than the scammer must have felt:

Honestly not sure what to type. We are f****d. This project has not had any venture backing, so it is highly unlikely there is any sort of bailout coming.

Beanstalk has tried the approach that seemed to work for De-Fi outfit Poly Networks last year, when a hacker made off with hundreds of millions due to a smart contract exploit: grovel politely, and ask for the money back.

The desperate Beanstalk operators sent a message via the ETHER blockchain to the scammer, whom they’ve dubbed The Exploiter, as follows:

496e207468652077616b65206f6620796573746572646179277320
61747461636b2c204265616e7374616c6b204661726d73206d616b
65732074686520666f6c6c6f77696e67206f6666657220746f2074
6865204578706c6f697465723a0a0a496620796f752077696c6c20
72657475726e20393025206f66207468652077697468647261776e
2066756e647320746f20746865204265616e7374616c6b20646570
6c6f796d656e742077616c6c657420307832314445313842364138
663738654465364431364335304131363766364232323244433038
4446372c204265616e7374616c6b2077696c6c2074726561742074
68652072656d61696e696e67203130252061732061205768697465
68617420626f756e74792070726f7065726c792070617961626c65
20746f20796f752e0a0a54686f7573616e6473206f6620696e6469
76696475616c732068617665206265656e206861726d656420616e
64207468697320697320616e206f70706f7274756e69747920746f
206d616b6520676f6f64206f6e2079657374657264617927732065
76656e74732e0a0a4265616e7374616c6b204661726d73

The message decodes as:

In the wake of yesterday's attack, Beanstalk Farms makes the following offer to the Exploiter: If you will return 90% of the withdrawn funds to the Beanstalk deployment wallet 0x21DE18B6A8f78eDe6D16C50A167f6B222DC08DF7, Beanstalk will treat the remaining 10% as a Whitehat bounty properly payable to you. Thousands of individuals have been harmed and this is an opportunity to make good on yesterday's events. Beanstalk Farms

Desperate times, it seems, call for desperate measures.

For all we know, the Exploiter might decide that it’s worth going for 10% of the “takings” paid in cryptocurrency wallets that the community may subsequently accept as “properly obtained…

…or they might just decide to keep the lot, and to avoid apparently admitting that the original heist amounted to an “improper” payment until it was retrospectively legitimised as a bug bounty.

Where do you stand on this heist and its response?

Was this a crime or simply a smart-but-legal trick?

Are retrospective bug bounties an acceptable last-ditch recovery tactic, or a copout?

Let us know in the comments below…

---

For the third time this year, Google’s Chrome browser has quietly received a security update together 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 one that’s used by Edge and many other mainstream browsers.

The V8 engine is also used in node.js, a standalone JavaScript programming ecosystem that’s very widely used these days as a server application language.

How bad is this bug?

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

In that case, Google wrote that the bugs uncovered had been traced back to two different North Korean cybercrime groups, and that attacks had apparently spanned the media, IT, cryptocurrency and fintech industries.

We’re not aware of any follow-up report for last month’s emergency patch – it’s possible, after all, that Google simply hasn’t traced the second lot of attacks back to their source yet…

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

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

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

Type confusion explained

“Type confusion” bugs are a class of memory mismanagement flaw where a memory block that’s supposed to used by one sort of calculation inadvertently gets consumed and trusted by a different algorithm.

For example, mixing up a 64-bit unsigned integer and a 64-bit floating point number will typically throw your calculation off horrendously, 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 the super-tiny 2^-1022 to the super-massive 2¹⁰²³, plus 52 bits representing the fractional part of the number.

So, the number 42 comes out as the following binary strings when packed into 8-byte memory blocks (we’ve 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 isn’t treated as a simple bit-string, but is broken down in 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 up the encodings?

If you mix the two encodings up, then you get the following bizarre results, turning the 64-bit integer version of 42 into a truly minuscule 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 could result in dangerous miscalculations, especially if the code that misinterprets the raw data assumes that the value can be trusted because it was already checked when the data was originally computed and stored.

What if you mix up something much worse?

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

For example, imagine that, as an attacker, you have a way to build an icon from a bitmap you provide, and your icon gets packed into a memory block 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 a precise pattern of up to 8 + 8 + 256 = 272 bytes in a memory block used by the app to represent an icon object.

As long as the app only ever 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 any harm (except, perhaps, to display a weird icon).

But now imagine that immediately after creating the icon memory buffer, you could trick the app into thinking that the data it just stored was a completely different sort 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 an imaginary situation, of course (it’s not representative of any known Chrome or JavaScript engine bug we’re aware of, now or in the past), but it helps you paint a mental picture of how just dangerous this sort of type confusion could be.

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

You could not only rig things up so that the app would call unwanted code in future (the generator function), but also so that it would write data of your choosing (the output of the generator), in an amount of your choosing (the iteration count), to a memory location of your choosing (via the output pointer).

What to do?

As always, ensure you have the latest version of Chrome.

Google has published two relevant security advisories: one for Windows, Mac and Linux, and a second but largely identical bulletin for Android.

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

Google’s Play Store doesn’t give precise details for Android users, saying, in its typically non-committal way, that the “Current Version varies with device”. (The most recent date given for an update, however, is listed as 2022-04-14.)

We notice that numerous unofficial Android download sites (no, we’re not going to recommend any; stick to Google Play if you can) already have the 100.0.4896.127 build available, so we’re guessing that many devices, presumably including Google’s own phones, therefore already have the latest version downloaded or ready to download.

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

If you haven’t updated yet, or if you’re not sure, you can do this:

• Google Chrome. Three-dot menu (⋮) > Help > About Chrome.
• 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.

Don’t delay; do it today!

---