Perpetual IT

Another week, another BWAIN!

As you’ll know if you listened to last week’s podcast (hint, hint!), BWAIN is short for Bug With An Impressive Name:

It’s a nickname we apply when the finders of a new cybersecurity attack get so excited about their discovery that they give it a PR-friendly moniker, register a vanity domain name for it, build it a custom website, and design it a special logo.

This time, the name Collide+Power includes a pesky punctuation character, which is a plus in bug naming, but a minus when registering an internet domain. (Ironically, domain names are allowed to use -, but not +).

So, the domain name had to be abbreviated slightly to https://collidepower.com, but the website will give you an overview of the problem anyway, even with the addition sign subtracted.

Collide cached data, and measure the power required

The researchers behind this new paper are Andreas Kogler, Jonas Juffinger, Lukas Giner, Martin Schwarzl, Daniel Gruss and Stefan Mangard from Graz University in Austria, and Lukas Gerlach and Michael Schwarz of the CISPA Helmholtz Center for Information Security in Germany.

We’re not going to try to explain the various forms of this attack at any length, because the technical details of how to take the measurements, and the mathematical modelling used to make inferences from those measurements, are complex.

But the core of the problem, if you will pardon the partial pun, is that the cache memory that’s buried inside modern processor chips, intended to provide an invisible and automatic performance boost…

…isn’t always quite as invisible as you might think, and may sometimes leak some or all of its content, even to processes that shouldn’t be able to see it.

As the name suggests, cache memory (it’s pronounced cash, as in dollars and cents, not cachet, as in respect and prestige, if you’ve ever wondered), keeps special copies of data values from conventional RAM in hidden locations inside the CPU chip itself.

If the CPU keeps track of the RAM addresses (memory locations) that you’ve used recently, and can guess well enough which ones you’re likely to use again soon, it can keep them temporarily in its cache memory and thus greatly speed up your second access to those values, and the third access, the fourth, and so on.

For example, if you’re looking up a series of data values in a table to convert image pixels from one colour format to another, you might find that most of the time the lookup table tells you to visit either RAM address 0x06ABCC00 (which might be where the special code for “black pixel” is stored) or address 0x3E00A040 (which might be the location of the “transparent pixel” code).

By automatically keeping the values from those two commonly-needed memory addresses in its cache, the CPU can short-circuit (figuratively, not literally!) future attempts to access those addresses, so that there’s no need to send electrical signals outside the processor, across the motherboard, and into the actual RAM chips to read out the master copy of the data that’s stored there.

So, cached data is usually much faster to access than data in motherboard RAM.

Generally speaking, however, you don’t get to choose which cache registers get used to store which RAM addresses, and you don’t get to choose when the CPU decides to stop caching your “transparent pixel code” value and start caching another program’s “super-secret cryptograpic key” instead.

Indeed, the cache may contain a liberal mix of values, from a liberal mixture of RAM addresses, belonging to a liberal mixture of different user accounts and privilege levels, all at the same time.

For this reason, along with reasons of efficiency and performance, even admin-level programs can’t directly peek at the list of addresses currently being cached, or get at their values, to protect the cached data against external snooping.

As a programmer, you still use the machine code instruction “read out the transparent pixel code from address 0x3E00A040”, and the operating system still decides whether you’re supposed to have access to that data based on the numerical adddress 0x3E00A040, even if the data ultimately comes directly from the cache instead of from the true RAM address 0x3E00A040.

The price of a bit-flip

What the Collide+Power researchers discovered, very greatly simplified, is that although you can’t directly peek at the temporary data in cache storage, and therefore can’t sidestep the memory protection that would be applied if you went via its official RAM address…

…you can guess when specific data values are about to be written into specific cache storage registers.

And when one already-cached number is being replaced by another, you can make inferences about both values by measuring how much power the CPU uses in the process.

(Modern processors usually include special internal registers that provide power usage readings for you, so you don’t need to crack open the computer case and attach a physical probe wire somewhere on the motherboard.)

Intriguingly, the power consumption of the CPU itself, when it overwrites a cache value with a new one, depends on how many bits changed between the numbers.

If we simplify matters to individual bytes, then overwriting the binary value 0b00000000 with 0b11111111 (changing decimal 0 to decimal 255) requires flipping all the bits in the byte, which would consume the most power.

Overwriting the ASCII character A (65 in decimal) with Z (90 in decimal) means changing 0b01000001 into 0b01011010, where four bit-positions get flipped, thus consuming a middling amount of power

And if the numbers happen to be the same, no bits need flipping, which would consume the least power.

In general, if you XOR the two numbers together and count the number of 1-bits in the answer, you find the number of flips, because 0 XOR 0 = 0 and 1 XOR 1 = 0 (so zero denotes no flip), while 0 XOR 1 = 1 and 1 XOR 0 = 1 (denoting a flip).

In other words, if you can access a bunch of chosen addresses of your own in a way that primes a specific set of cache registers inside the CPU, and then monitor the power consumption accurately enough when someone else’s code gets its data assigned to those cache locations instead…

…then you can make inferences about how many bits flipped between the old cache contents and the new.

Of course, you get to choose the values stored in the addresses with which you primed the cache registers, so you don’t just know how many bits probably flipped, but you also know what the starting values of those bits were before the flips took place.

That gives you yet more statistical data with which to predict the likely new values in the cache, given that you know what was there before and the likely number of bits that are now different.

You might not be able to figure out exactly what data your victim’s process was using, but even if you can eliminate some bit patterns, you’ve just learned something that you’re not supposed to know.

And if that data were, say, an encryption key of some sort, you might be able to convert a unfeasible brute force attack into an attack where you might just succeed.

For example, if you can predict 70 bits in a 128-bit encryption key, then instead of trying out all combinations of 128 bits, which would be an impossible task, you’d need to try 2⁵⁸ different keys instead (128 – 70 = 58), which might very well be feasible.

No need to panic

Fortunately, this “vulnerability” (now dubbed CVE-2023-20583) is unlikely to be used against you any time soon.

It’s more of a theoretical matter that chip manufacturers need to take into account, on the basis of the truism that cybersecurity attacks “only ever get better and faster”, than an exploitable hole that could be used today.

In fact, the researchers admit, almost sheepishly, that “you do not need to worry.”

They really did write you in italics, and the imprecation not to worry in bold:

In the conclusion of the paper, the researchers ruefully note that some of their best real-world results with this attack, under ideal lab conditions, leaked just 5 bits an hour.

For one of their attack scenarios, in fact, they admitted that they encountered “practical limitations leading to leakage rates of more than [one] year per bit”.

Yes, you read that correctly – we checked it several time in the paper just to make sure we weren’t imagining it.

And that, of course, raises the question, “How long do you have to leave a collection of data transfer tests running before you can reliably measure transmission rates that low?”

By our calculations, one bit per year gives you about 125 bytes per millennium. At that rate, downloading the recently released three-hour blockbuster movie Oppenheimer in IMAX quality, which apparently takes up about half a terabyte, would take approximately 4 billion years. To put that bizarre factoid into perspective, Earth itself is only about 4.54 billion years old, give or take a few hundred million months.

What to do?

The simplest way to deal with CVE-2023-20538 right now is to do nothing, given that the researchers themselves have advised you not to worry.

If you feel the need to do something, both Intel and AMD processors have ways to reduce the accuracy of their power measurement tools on purpose, by adding random noise into the power readings.

This leaves your averages correct but varies individual readings sufficiently to make this already not-really-feasible attack even harder to pull off.

Intel’s power measurement mitigation is known as running average power limit (RAPL) filtering; AMD’s is referred to as performance determinism mode.

The latest full new version of Firefox is out, marking the first of two “monthly” upgrades you’ll see this month.

Just as there will be a blue moon in August 2023 (that’s the name applied to a second full moon in the same calendar month, rather than reference to an atmospheric phenomenon that makes the moon seem blue, in case you ever wondered), there will be a blue Firefox too.

Firefox version upgrades happen every 28 days, rather than once a month, so whenever a release comes out early enough in the month, there will be a second upgrade squeezed in at the end.

Teachable moments

Fortunately there are no zero-day vulnerabilities this time, but the following bug reports caught our eye:

• CVE-2023-4045: Offscreen Canvas could have bypassed cross-origin restrictions. One webpage could peek at images displayed in another page from a different site. The same-origin policy in browsers is supposed to restrict the reach of HTML and JavaScript content from site X so it can access forms, data, images, cookies and the like only if they too originally came from site X. Any tricks that can bypass this same-origin protection can theoretically be used to slurp up so-called cross-origin data that shouldn’t be accessible at all.
• CVE-2023-4047: Potential permissions request bypass via clickjacking. A rogue page could tempt you to click on a carefully-placed item, such as an entirely innocent-looking button, only for the input to register as a click in a security dialog that didn’t pop up in time for you to see. Potentially risky permissions, such as accessing your location, sending notifications, activating the microphone and so on, are not supposed to be granted until you’ve seen and acted on a clear warning from the browser itself.
• CVE-2023-4048: Crash in DOMParser due to out-of-memory conditions. DOM is short for document object model, and the DOMParser is the code that deconstructs the HTML in a web page that the browser is rendering for display, turning it into a big JavaScript data object in which all the individual components such as paragraphs, headings, images, table items and so on can be accessed and modified programmatically. Complex pages typically turn into large JavaScript structures that can take a lot of memory to figure out and then to store. Assume that a determined attacker could deliberately eat up memory by loading a number of large but innocent pages, and then predictably trigger a crash using a crafted HTML file that gets fetched at just the wrong time.
• CVE-2023-4050: Stack buffer overflow in StorageManager. This is an old-school stack overflow that doesn’t get detected in time by Firefox itself, and could therefore lead to a crash instead of a controlled shutdown. All crashes caused by the incorrect flow of execution in a program (such as jumping to any invalid memory address X) should be considered potentially exploitable. Assume that a determined attacker could figure out how to influence the value of X, and thereby gain at least some measure of malevolent control over the crash.
• CVE-2023-4051: Full screen notification obscured by file open dialog. Fullscreen mode is always a bit risky, because it gives the web page you’re viewing precise control over every pixel on the screen. This means that there are no parts of the display that can be modified only by the browser itself or only by the operating system. That’s why browsers aim to warn you before giving over the whole display to a web page, so you know that popups that look like official browser or operating system dialogs might be no such thing.
• CVE-2023-4057 and CVE-2023-4058: Memory safety bugs fixed in various Firefox versions. As usual, even though none of these bugs was obviously exploitable, and they were fixed proactively anyway, Mozilla has rated them “High” and given its ever-frank assessment that “we presume that with enough effort some of these could have been exploited to run arbitrary code.”

What to do?

The new versions you are looking for after updating are:

• Firefox 116 if you’re on the latest version.
• Firefox ESR 115.1 if you are a user of the Extended Support Release, which includes security patches but doesn’t add new features. (Adding 115+1 from the ESR version number tells you that this release aligns with Firefox 116 for security fixes, even though its feature set aligns with Firefox 115.)
• Thunderbird 115.1 if you use Mozilla’s email software, which includes the Firefox web browsing code for rendering HTML emails and viewing emailed web links.

Head to Firefox -> About Firefox if you have a Mac, or Help -> About Firefox on other platforms.

Dont forget, if you use one of the BSDs or a Linux distro, that your Firefox release might be managed by the distro itself, so check with your provider for updates.

Last week, the US Securities and Exchange Commission (SEC) announced new and fairly strict rules about cybersecurity breach disclosures for any people or companies that fall under its regulatory remit.

The SEC, by the way, was founded at the height of the US Great Depression in the 1930s, with the aim of preventing the sort of unregulated speculation that led to what became known as Black Thursday, the infamous Wall Street crash of 24 October 1929.

In its own words:

The mission of the SEC is to protect investors; maintain fair, orderly, and efficient markets; and facilitate capital formation.

The SEC strives to promote a market environment that is worthy of the public’s trust.

Simply put, if you’re running a company that offers shares to the public, you need to comply with the rules and regulations of the SEC, which are supposed to give your investors some sort of protection against unsubstantiated claims that disingenuously talk up a proposal, or that sneakily misrepresent the level of risk involved.

As you can imagine, especially in an online world in which ransomware breaches can bring a company to a digital standstill overnight, and where even coughing up a multimillion-dollar blackmail payment to the attackers for a “recovery program” might not be enough to get things going again…

…cybersecurity lapses can have dramatic, long-term effects on the value of a business investment.

Demanding money with menaces

Ransomware attacks these days frequently involve cybercriminals stealing copies of your trophy data first, notably including employee and customer details, and then scrambling your copies of those very same files, thus squeezing you into a double-play cybersecurity drama.

They’ve got your files, typically including heaps of data that you were duty bound to keep to yourself, and that you had probably promised quite openly that you could be trusted with.

But you haven’t got those files any more, in any meaningful sense.

Ironically, in a typical file-scrambling ransomware attack, you can see all your files still sitting there, often with their original filenames preserved, apparently right there within clicking distance, but no more use when you try to open them than a digital pile of shredded cabbage.

Because of this double-play scenario, ransomware isn’t quite the right word these days, given that a ransom is a sum that you pay for the safe return of someone or something you want back, whether that’s a kidnapped medieval monarch or a pile of 21st-century data files.

After all, today’s “ransomware attacks” have several different ways of unfolding, including:

• Type A. Your files are locked up, and only the crooks have the decryption key. Pay the exortion fee and the crooks will (or so they say) not only send you the key, but also keep quiet about what happened, so that you don’t have to admit that your temporary business outage was due to a cyberintrusion. Refuse to pay and you’re on your own. Organisations without a practicable disaster recovery plan might never get their business back on the rails at all.
• Type B. Your files are copied, and the crooks have them all. Pay the extortion fee and they’ll delete the stolen data (or so they say) to shield you from data breach lawsuits from staff and customers, to stop the regulators from digging too deeply, and to help you keep your reputation intact. Refuse to pay and you’ll be firmly in the public eye, exposed as an organisation that can’t be trusted.
• Type C. Both of the above.

As you can see, attacks of Type B can be pulled off even if the criminals don’t manage, or don’t want the risk of trying, to break into your network and getting access to every file directly on your own laptops, desktops and servers.

In the recent MOVEit attacks, for example, cybercrime operators allegedly working under the banner of the notorious Clop ransomware gang got hold of huge amounts of private data from numerous high-profile organisations, but without breaching those organisations directly.

Instead, the criminals went after third-party service companies such as payroll providers that transfered and stored copies of those organisations’ trophy data using the fourth-party data management product MOVEit Transfer and its online equivalent MOVEit Cloud:

And attacks of Type A can be carried out swiftly and directly, without any file exfiltration in advance, by cybercriminals who don’t want to risk getting spotted trying to upload large amounts of data.

Some crooks take that approach because any unexpected spike in outbound network traffic is a popular indicator of compromise (IoC) that businesses are learning to look out for.

In Type A ransomware attacks, the crooks don’t actually need to generate any outbound network traffic at all – not even to keep control of the magic decryption keys for each computer.

They can asymmetrically encrypt those master keys into files left behind on each affected computer, using a public key for which only they have the corresponding private key.

What a public key has locked up can’t be unlocked by that public key; only the holder of the matching private key can do that. (Think of an unlocked padlock: anyone can click it shut, but only the person with the physical key can open it up again.)

Thus the master key data is right there in plain sight, but useless to you without the necessary private key that the attackers prepared offline in advance.

All the crooks need to do is to leave behind a message telling you how to get in touch with them to start “negotiating” to buy the private key off them.

When is a ransomware attack a notifiable breach?

One thing that’s never been obvious is just how ransomware attacks and existing data breach regulations intersect.

If you get hit by a Type A attack, but there’s no evidence that unencrypted data was exfiltrated, and you successfully restore from backups overnight and get your business back on track again quickly…

…should you be forced to tell anyone, and if so what other sorts of and scales of malware infection or data corruption should be declared too?

If you get hit by a Type B attack, and after paying the crooks off promptly you are inclined to believe that they really did delete the data so that they can no longer disclose it…

…can you reasonably define it as not-a-breach, because the data was apparently “unbreached” by the attackers, and thus no harm was ultimately done?

Indeed, if you pay out a cyberblackmail fee for any reason at all…

…should you disclose that in all cases, even where criminal law doesn’t require you to?

Unfortunately, but understandably given that this is an initial announcement, the SEC’s press release doesn’t go into that sort of detail.

Instead, it just says that those under its remit, referred to as registrants, are:

[…required to] disclose material cybersecurity incidents they experience and to disclose on an annual basis material information regarding their cybersecurity risk management, strategy, and governance.

The new rules will require registrants to disclose […] any cybersecurity incident they determine to be material and to describe the material aspects of the incident’s nature, scope, and timing, as well as its material impact or reasonably likely material impact on the registrant.

[The disclosure] will generally be due four business days after a registrant determines that a cybersecurity incident is material.

The disclosure may be delayed if the United States Attorney General determines that immediate disclosure would pose a substantial risk to national security or public safety and notifies the Commission of such determination in writing.

Should paying off Type B cyberextortionists be considered “a material impact”, for example, because you can never really be sure that the crooks won’t come back for more, or that the data they stole wasn’t stolen by someone else while they had unauthorised hold of it?

Should getting hit by Type A ransomare criminals be considered “a material impact”, and if so what should the guidelines be for the scale of the attack?

In a business with a network of 100 computers, for example, how many computers would need to be scrambled in the course of a single ransomware incident for the attack to be considered likely to have exposed the business to more than just the side-effect of some ruined files?

Have your say in the comments below…

ONE WEEK, TWO BWAINS

Apple patches two zero-days, one for a second time. How a 30-year-old cryptosystem got cracked. All your secret are belong to Zenbleed. Remembering those dodgy PC/Mac ads.

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 and anywhere that good podcasts are found. Or just drop the URL of our RSS feed into your favourite podcatcher.

READ THE TRANSCRIPT

Remember Heartbleed?

That was the bug, back in 2014, that introduced the suffix -bleed for vulnerabilities that leak data in a haphazard way that neither the attacker nor the victim can reliably control.

In other words, a crook can’t use a bleed-style bug for a precision attack, such as “Find the shadow password file in the /etc directory and upload it to me,” or “Search backwards in memory until the first run of 16 consecutive ASCII digits; that’s a credit card number, so save it for later.”

In Heartbleed, for example, you could trick an unpatched server into sending a message that was supposed to be at most 16 bytes long, but that wrongly included up to about 64,000 additional bytes tacked on the end.

You didn’t get to choose what was in those 64,000 plundered bytes; you just got whatever happened to be adjacent in memory to the genuine message you were supposed to receive.

Sometimes, you’d get chunks of all zeros, or unknown encrypted data for which you didn’t have the decryption key…

…but every now and then you’d get leftover cleartext fragments of a web page that the previous visitor downloaded, or parts of an email that someone else just sent, or even memory blocks with the server’s own private cryptographic keys in it.

Plentiful needles in endless haystacks

Attackers typically exploit bleed-based bugs simply by triggering them over and over again automatically, collecting a giant pile of unauthorised data, and then combing through it later at their leisure.

Needles are surprisingly easy to extract from haystacks if (a) you can automate the search by using software to do the hard work for you, (b) you don’t need answers right away, and (c) you’ve got lots and lots of haystacks, so you can afford miss many or even most of the needles and still end up with a sizeable stash.

Other bleed-named bugs include Rambleed, which deliberately provoked temporary memory errors in order to guess what was stored in nearby parts of a RAM chip, and Optionsbleed, where you could ask a web server over and over again which HTTP options it supported, until it sent you a reply with someone else’s data in it by mistake.

In analogy, a bleed-style bug is a bit like a low-key lottery that doesn’t have any guaranteed mega-jackpot prizes, but where you get a sneaky chance to buy 1,000,000 tickets for the price of one.

Well, famous Google bug-hunter Tavis Ormandy has just reported a new bug of this sort that he’s dubbed Zenbleed, because the bug applies to AMD’s latest Zen 2 range of high-performance processors.

Unfortunately, you can exploit the bug from almost any process or thread on a computer and pseudorandomly bleed out data from almost anywhere in memory.

For example, a program running as an unprivileged user inside a guest virtual machine (VM) that’s supposed to be sealed off from the rest of the system might end up with data from other users in that same VM, or from other VMs on the same computer, or from the host program that is supposed to be controlling the VMs, or even from the kernel of the host operating system itself.

Ormandy was able to create proof-of-concept code that leaked about 30,000 bytes of other people’s data per second per processor core, 16 bytes at a time.

That might not sound like much, but 30KB/sec is sufficient to expose a whopping 3GB over the course of a day, with data that’s accessed more regularly (including passwords, authentication tokens and other data that’s supposed to be kept secret) possibly showing up repeatedly.

And with the data exposed in 16-byte chunks, attackers are likely to find plenty of recognisable fragments in the captured information, helping them to sift and sort the haystacks and focus on the needles.

The price of performance

We’re not going to try to explain the Zenbleed flaw here (please see Tavis Ormandy’s own article for details), but we will focus on the reason why the bug showed up in the first place.

As you’ve probably guessed, given that we’ve already alluded to processes, threads, cores and memory management, this bug is a side-effect of the internal “features” that modern processors pack in to improve performance as much as they can, including a neat but bug-prone trick known in the trade as speculative execution.

Loosely speaking, the idea behind speculative execution is that if a processor core would otherwise be sitting idle, perhaps waiting to find out whether it’s supposed to go down the THEN or the ELSE path of an if-then-else decision in your program, or waiting for a hardware access control check to determine whether it’s really allowed to use the data value that’s stored at a specific memory address or not…

…then it’s worth ploughing on anyway, and calculating ahead (that’s the “speculative execution” part) in case the answer comes in handy.

If the speculative answer turns out to be unnecessary (because it worked out the THEN result when the code went down the ELSE path instead), or ends up off-limits to the current process (in the case of a failed access check), it can simply be discarded.

You can think of speculative execution like a quiz show host who peeks at the answer at the bottom of the card while they’re asking the current question, assuming that the contestant will attempt to answer and they’ll need to refer to the answer straight away.

But in some quiz shows the contestant can say “Pass”, skipping the question with a view to coming back to it later on.

If that happens, the host needs to put the unused answer out of their mind, and plough on with the next question, and the next, and so on.

But if the “passed” question does come round again, how much will the fact that they now know the answer in advance affect how they ask it the second time?

What if they inadvertently read the question differently, or use a different tone of voice that might give the contestant an unintended hint?

After all, the only true way to “forget” something entirely is never to have known it in the first place.

The trouble with vectors

In Ormandy’s Zenbleed bug, now officially known as CVE-2023-20593, the problem arises when an AMD Zen 2 processor performs a special instruction that exists to set multiple so-called vector registers to zero at the same time.

Vector registers are used to store data used by special high-performance numeric and data processing instructions, and in most modern Intel and AMD processors they are a chunky 256 bits wide, unlike the 64 bits of the CPU’s general purpose registers used for traditional programming purposes.

These special vector registers can typically be operated on either 256 bits (32 bytes) at a time, or just 128 bits (16 bytes) at a time.

In fact, for historical reasons, today’s CPUs have two completely different sets of vector-style machine code instructions: a newer bunch known as AVX (advanced vector extensions), which can work with 128 or 256 bits, and an older, less powerful group of instructions called SSE (streaming SIMD extensions, where SIMD in turn stands for single-instruction/mulitple data), which can only work with 128 bits at a time.

Annoyingly, if you run some new-style AVX code, then some old-style SSE code, and then some more AVX code, the SSE instructions in the middle mess up the top 128 bits of the new-fangled 256-bit AVX registers, even though the SSE instructions are, on paper at least, only doing their calculations on the bottom 128 bits.

So the processor quietly saves the top 128 bits of the AVX registers before switching into backwards-compatible SSE mode, and then restores those saved values when you next start using AVX instructions, thus avoiding any unexpected side-effects from mixing old and new vector code.

But this save-and-restore process hurts performance, which both Intel’s and AMD’s programming guides warn you about strongly.

AMD says:

There is a significant penalty for mixing SSE and AVX instructions when the upper 128 bits of the [256-bit-wide] YMM registers contain non-zero data.

Transitioning in either direction will cause a micro-fault to spill or fill the upper 128 bits of all sixteen YMM registers.

There will be an approximately 100 cycle penalty to signal and handle this fault.

And Intel says something similar:

The hardware saves the contents of the upper 128 bits of the [256-bit-wide] YMM registers when transitioning from AVX to SSE, and then restores these values when transitioning back […]

The save and restore operations both cause a penalty that amounts to several tens of clock cycles for each operation.

To save the day, there’s a special vector instruction called VZEROUPPER that zeros out the top 128 bits of each vector register in one go.

By calling VZEROUPPER, even if your own code doesn’t really need it, you signal to the processor that you no longer care about the top 128 bits of those 256-bit registers, so they don’t need saving if an old-school SSE instruction comes along next.

This helps to speed up your code, or at least stops you from slowing down anyone else’s.

And if this sounds like a bit of a kludge…

…well, it is.

It’s a processor-level hack, if you like, just to ensure that you don’t reduce performance by trying to improve it.

Where does CVE-2023-20593 come in?

All of this fixation on performance led Ormandy to his Zenbleed data leakage hole, because:

• AVX code is extremely commonly used for non-mathematical purposes, such as working with text. For example, the popular Linux programming library glibc uses AVX instructions and registers to speed up the function strlen() that’s used to find the length of text strings in C. (Loosely speaking, strlen() using AVX code lets you search through 16 bytes of a string at a time looking for the zero byte that denotes where it ends, instead of using a conventional loop that checks byte-by-byte.)
• AMD’s Zen 2 processors don’t reliably undo VZEROUPPER when a speculative execution code path fails. When “unzeroing” the top 128 bits of a 256-vector register because the processor guessed wrongly and the VZEROUPPER operation needs to be reversed, the register sometimes ends up with 128 bits (16 bytes) “restored” from someone else’s AVX code, instead of the data that was actually there before.

In real life, it seems that programmers rarely use VZEROUPPER in ways that need reversing, or else this bug might have been found years ago, perhaps even during development and testing at AMD itself.

But by experimenting carefully, Ormandy figured out how to craft AVX code loops that not only repeatedly triggered the speculative execution of a VZEROUPPER instruction, but also regularly forced that instruction to be rolled back and the AVX registers “unzeroed”.

Unfortunately, lots of other conventional programs use AVX instructions heavily, even if they’re not the sort of applications such as games, image rendering tools, password crackers or cryptominers that you’d expect to need high-speed vector-style code.

Your operating system, email client, web browser, web server, source code editor, terminal window – pretty much every program you use routinely – almot certainly uses its fair share of AVX code to improve performance.

So, even under very typical conditions, Ormandy sometimes ended up with the ghostly remnants of other programs’ data mixed into his own AVX data, which he could detect and track.

After all, if you know what’s supposed to be in the AVX registers after a VZEROUPPER operation gets rolled back, it’s easy to spot when the values in those registers go awry.

In Ormandy’s own words:

[B]asic operations like strlen(), memcpy() and strcmp() [find text string length, copy memory, compare text strings] will use the vector registers – so we can effectively spy on those operations happening anywhere on the system!

It doesn’t matter if they’re happening in other virtual machines, sandboxes, containers, processes, whatever.

As we mentioned earlier, if you’ve got a daily pool of 3GB of unstructured, pseudorandomly selected ghost data per CPU core, you might not hit the lottery equivalent of a multi-million-dollar jackpot.

But you’re almost certain to win the equivalent of thousands of $1000 prizes, without riskily poking your nose into other people’s processes and memory pages like traditional “RAM snooping” malware needs to do.

What to do?

CVE-2023-20593 was disclosed responsibly, and AMD has already produced a microcode patch to mitigate the flaw.

If you have a Zen 2 family CPU and you’re concerned about this bug, speak to your motherboard vendor for further information on how to get and apply any relevant fixes.

On operating systems with software tools that support tweaking the so-called MSRs (model-specific registers) in your processor that control its low-level configuration, there’s an undocumented flag (bit 9) you can set in a poorly-documented model register (MSR 0xC0011029) that apparently turns off the behaviour that causes the bug.

MSR 0xC0011029 is referred to in the Linux kernel mailing list archives as the DE_CFG register, apparently short for decode configuration, and other well-known bits in this register are used to regulate other aspects of speculative execution.

We’re therefore guessing that DE_CFG[9], which is shorthand for “bit 9 of MSR 0xC0011029”, decides whether to allow instructions with complex side-effects such as VZEROUPPER to be tried out speculatively at all.

Obviously, if you never allow the processor to zero out the vector registers unless you already know for sure that you’ll never need to “unzero” those registers and back out the changes, this bug can never be triggered.

The fact that this bug wasn’t spotted until now suggests that real-world speculative execution of VZEROUPPER doesn’t happen very often, and thus that this low-level hack/fix is unlikely to have a noticeable impact on performance.

Ormandy’s article includes a description of how to reconfigure the relevant MSR bit in your Zen 2 processor on Linux and FreeBSD.

(You will see DE_CFG[9] described as a chicken bit, jargon for a configuration setting you turn on to turn off a feature that you’re scared of.)

OpenBSD, we hear, will be forcing DE_CFG[9] on automatically on all Zen 2 processors, thus suppressing this bug by default in search of security over performance; on Linux and other BSDs, you can do it with command line tools (root needed) such as wrmsr and cpucontrol.

Mac users can relax because non-ARM Macs all have Intel chips, as far as we know, rather than AMD ones, and Intel processors are not known to be vulnerable to this particular bug.

Windows users may need to fall back on unofficial kernel driver hacks (avoid these unless you really know what you’re doing, because of the security risks of booting up in “allow any old driver” mode), or to install the official WinDbg debugger, enable local kernel debugging, and use a WinDbg script to tweak the relevant MSR.

(We admit that haven’t tried any of these mitigations, because we don’t have an AMD-based computer handy at the moment; please let us know how you get on if you do!)