Performance and security clash yet again in “Collide+Power” attack

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 258 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:

Conclusion on the BWAIN site.

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.


Firefox fixes a flurry of flaws in the first of two releases this month

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.


SEC demands four-day disclosure limit for cybersecurity breaches

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…


S3 Ep145: Bugs With Impressive Names!

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.

No audio player below? Listen directly on Soundcloud.

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

DOUGLAS.  Apple patches, security versus performance, and hacking police radios.

All that, and more, on the Naked Security podcast.

[MUSICAL MODEM]

Welcome to the podcast, everybody.

I am Doug Aamoth; he is Paul Ducklin.

Paul, what’s up, buddy?


DUCK.  It’s July, Douglas!


DOUGLAS.  Well, let’s talk about July in our This Week in Tech History segment.

28 July 1993 brought us version 1.0 of the Lua programming language.

And even if you’ve never heard of the Little Language That Could, you’ve probably benefitted from it.

Lua is used in apps such as Roblox, World of Warcraft, Angry Birds, web apps from Venmo and Adobe, not to mention Wireshark, Nmap, Neovim, and zillions more widespread scriptable apps.

Paul, you use Lua in some of the Naked Security articles, if I’m not mistaken.


DUCK.  I’m a big Lua fan, Douglas.

I use it quite extensively for my own scripting.

It’s what I like to call a “lean, mean fighting machine”.

It’s got some lovely characteristics: it’s a very easy language to learn; it’s very easy language to read; and yet you can even write programs in functional style.

(Speaking technically, functions are first-class objects in the language, so you can do all sorts of neat stuff that you can’t do with more traditional languages like C.)

And I often use it for what would otherwise be pseudocode in Naked Security articles.

Because (A) you can copy-and-paste the code and try it out for yourself if you want, and (B) it is actually surprisingly readable, even for people who aren’t familiar with programming.

Lua comes from Rio de Janeiro in Brazil.
The word Lua imeans ‘moon’ in Portuguese.


DOUGLAS.  Lovely!

Alright, let’s stay on the subject of code.

We’ve talked several times now about Apple’s second Rapid Response patch.

It was there, it wasn’t there, what happened to it?

Well, that patch is now part of a full update, and one which actually patched a second zero-day as well, Paul.

Apple ships that recent “Rapid Response” spyware patch to everyone, fixes a second zero-day


DUCK.  Yes.

If you remember that Rapid Response, like you said…

…there was an update with version (a), which is how they denote the first one, then there was a problem with that (browsing to some websites that weren’t parsing User-Agent strings properly).

And so Apple said, “Oh, don’t worry, we’ll come out with version (b) in a bit.”

And then the next thing we saw was version (c).

You’re right, the idea of these Rapid Responses is they do eventually make it into the full upgrades, where you get a full new version number.

So, even if you’re fearful of Rapid Responses, you will get those fixes later, if not sooner.

And the zero-day in WebKit (that was the Rapid-Response-patched thing) has now been accompanied by a zero-day fix for a kernel-level hole.

And there are some (how can I put it?) “interesting co-incidences” when you compare it with Apple’s last major security upgrade back in June 2023.

Namely that the zero-day fixed in the Rapid Response part was in WebKit, and was attributed to “an anonymous researcher”.

And the zero-day now patched in the kernel was attributed to Russian anti-virus outfit Kaspersky, who famously reported that they’d found a bunch of zero-days on their own executives’ iPhones, presumably used for a spyware implant.

So the smart money is saying, even though Apple didn’t explicitly mention this in their security bulletins, that this is yet another fix related to that so called Triangulation Trojan.

In other words, in-the-wild spyware that was used in at least some targeted attacks.

That makes the Rapid Response yet more understandable (as to why Apple wanted to get it out quickly), because that stops the browser being used to trick your phone in the first place.

And it makes this upgrade super-important, because it means it’s closing off the hole-behind-the-hole that we imagine crooks would use after compromising your browser.

They’d be chaining to this second vulnerability that gave them, essentially, complete control.


DOUGLAS.  OK, so we go from two weeks ago to 30 years ago…

…and this is such an interesting story.

It’s a cautionary tale about not trying to keep cryptographic secrets hidden behind non-disclosure agreements. [NDAs]

Complete with a new BWAIN, Paul.

We’ve got a new BWAIN!

Hacking police radios: 30-year-old crypto flaws in the spotlight


DUCK.  “Bug With An Impressive Name.”

If keeping the algorithm secret is necessary for it to work correctly…

…it only takes one person to take a bribe, or to make a mistake, or to reverse-engineer your product, for the whole thing to fall apart.

And that’s what this TETRA radio system did.

It relied on non-standard, proprietary, trade-secret encryption algorithms, with the result that they never really got much scrutiny over the years.

TETRA is Terrestrial Trunked Radio.

It’s kind-of like mobile telephony, but with some significant advantages for people like law enforcement and first responders, namely that it has a longer range, so you need far fewer base stations.

And it was designed from the outset with one-to-one and one-to-many communications, which is ideal when you’re trying to co-ordinate a bunch of people to respond to an emergency.

Unfortunately, it turned out to have some imperfections that were only discovered in 2021 by a bunch of Dutch researchers.

And they’ve been patiently waiting nearly two years to do their responsible disclosure, to come out with their details of the bugs, which they’ll be doing at a bunch of conferences, starting with Black Hat 2023.

You can understand why they want to make a big splash about it now, because they’ve been sitting on this information, working with vendors to get patches ready, since late 2021.

In fact, the CVEs, the bug numbers that they got, are all CVE-2022-xxxx, which just indicates how much inertia there is in the system that they’ve had to overcome to get patches out for these holes.


DOUGLAS.  And our BWAIN is TETRA:BURST, which is exciting.

Let’s talk about some of these holes.


DUCK.  There are five CVEs in total, but there are two main issues that I would think of as “teachable moments”.

The first one, which is CVE-2022-24401, deals with the thorny issue of key agreement.

How do your base station and somebody’s handset agree on the key they’re going to use for this particular conversation, so that it is reliably different from any other key?

TETRA did it by relying on the current time, which clearly only moves in a forward direction. (So far as we know.)

The problem is there was no data authentication or verification stage.

When the handset connects to the base station and gets the timestamp, it doesn’t have a way of checking, “Is this a real timestamp from a base station I trust?”

There was no digital signature on the timestamp, which meant that you could set up a rogue base station and you could trick them into talking to you using *your* timestamp.

In other words, the encryption key for a conversation from somebody else *that you already intercepted and recorded yesterday*…

…you could have a conversation today innocently with somebody, not because you wanted the conversation, but because you wanted to recover the keystream.

Then you could use that keystream, *because it’s the same one that was used yesterday*, for a conversation that you intercepted.

And, of course, another thing you could do is, if you figured that you wanted to be able to intercept something next Tuesday, you could trick someone into having a conversation with you *today* using a fake timestamp for next week.

Then, when you intercept that conversation in the future, you can decrypt it because you got the keystream from the conversation you had today.


DOUGLAS.  OK, so that’s the first bug.

And the moral of the story is: Don’t rely on data you can’t verify.

In the second bug, the moral of the story is: Don’t build in backdoors or other deliberate weaknesses.

That is a big no-no, Paul!


DUCK.  It is indeed.

That one is CVE 2022-24402.

Now, I’ve seen in the media that there’s been some argumentation about whether this really counts as a backdoor, because it was put in on purpose and everyone who signed the NDA knew that it was in there (or should have realised).

But let’s call it a backdoor, because it’s a deliberately-programmed mechanism whereby the operators of some types of device (fortunately not the ones generally sold to law enforcement or to first responders, but the one sold to commercial organisations)….

…there’s a special mode where, instead of using 80-bit encryption keys, there’s a magic button you can press that says, “Hey, guys, only use 32 bits instead of 80.”

And when you think that we got rid of DES, the data encryption standard, around the turn of the millennium because it only had 56-bit keys, you can imagine, *today in 2023*, just how weak a 32-bit encryption key really is.

The time-and-materials cost of doing a brute-force attack is probably trivial.

You can imagine, with a couple of half-decent laptops, that you could do it in an afternoon for any conversation that you wished to decrypt.


DOUGLAS.  Alright, very good.

Last, but not least, we have…

…if you remember Heartbleed back in 2014, don’t panic, but there’s a new thing called Zenbleed

Zenbleed: How the quest for CPU performance could put your passwords at risk


DUCK.  Yes, it’s BWAIN Number Two of the week. [LAUGHS]


DOUGLAS.  Yes, it’s another BWAIN! [LAUGHTER]


DUCK.  I was minded to write this up because it’s got a cute name, Zenbleed (the name “Zen” comes from the fact that the bug applies to AMD’s Zen 2 processor series, as far as I know), and because this one was found by legendary bug-hunter from Google Project Zero, Tavis Ormandy, who’s been turning his attention to what happens inside processors themselves.

“Bleed” attacks… I’ll just describe them using the words that I wrote in the article:


The suffix “-bleed” is used for vulnerabilities that leak data in a haphazard way that neither the attacker nor the victim can really control.


So a bleed attack is one where you can’t poke a knitting needle into a computer across the Internet and go, “Aha! Now I want you to find that specific database called sales.sql and upload it to me.”

And you can’t stick a knitting needle in another hole and go, “I want you to watch memory offset 12 until a credit card number appears, and then save it to disk for later.”

You just get pseudorandom data that leaks out of other people’s programs.

You get arbitrary stuff that you’re not supposed to see, that you can collect at will for minutes, hours, days, even weeks if you want.

Then you can do your big-data work on that stolen stuff, and see what you get out of it.

So that’s what Tavis Ormandy found here.

It’s basically a problem with vector processing, which is where Intel and AMD processors work not in their normal 64-bit mode (where they can, say, add two 64-bit integers together in one go), but where they can work on 256-bit chunks of data at a time.

And that’s useful for things like password cracking, cryptomining, image processing, all sorts of stuff.

It’s a whole separate instruction set inside the processor; a whole separate set of internal registers; a whole set of fancy and really powerful calculations that you can do on these super-big numbers for super-big performance results.

What’s the chance that those are bug free?

And that’s what Tavis Ormandy went looking for.

He found that a very special instruction that is largely used to avoid reducing performance…

…you have this magical instruction called VZEROUPPER that tells the CPU, “Because I’ve been using these fancy 256-bit registers but I’m no longer interested in them, you don’t have to worry about saving their state for later.”

Guess what?

This magic instruction, which sets the top 128 bits of all 256-bit vector registers to zero at the same time, all with one instruction (you can see there’s a lot of complexity here)…

…basically, sometimes it leaks data from some other processes or threads that have run recently.

If you abuse this instruction in the right way, and Tavis Ormandy found out how to do this, you do your own magic vector instructions and you use this super-cool VZEROUPPER instruction in a special way, and what happens is that the vector registers in your program occasionally start showing up with data values that they’re not supposed to have.

And those data values aren’t random.

They’re actually 16-byte (128-bit) chunks of data *that came from somebody else’s process*.

You don’t know whose.

You just know that this rogue data is making its ghostly appearance from time to time.

Unfortunately, Taviso discovered that by misusing this instruction in the right/wrong sort of way, he could actually extract 30KB of rogue, ghostly data from other people’s processes per second per CPU core.

And although that sounds like a very slow data rate (who would want 30KB per second on an internet connection these days? – nobody)…

…when it comes to getting random 16-byte chunks of data out of other people’s programs, it actually works out at about 3GB per day per core.

There are going to be bits of other people’s web pages; there are going to be usernames; there might be password databases; there might be authentication tokens.

All you have to do is go through this extensive supply of haystacks and find any needles that look interesting.

And the really bad part of this is *it’s not just other processes running at the same privilege level as you*.

So if you’re logged in as “Doug”, this bug doesn’t just spy on other processes running under the operating system account “Doug”.

As Taviso himself points out:


Basic operations like strlen, memcpy, and strcmp


(Those are standard functions that all programs use for finding the length of text strings, for copying memory around, and for comparing two items of text.)


Those basic operations will use vector registers, so we can effectively use this technique to spy on those operations happening anywhere on the system!


And he allowed himself, understandably, an exclamation point, right there.


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


I think he actually used a second exclamation point there as well.

In other words, *any process*, whether it’s the operating system, whether it’s another user in the same VM as you, whether it’s the program that controls the VM, whether it’s a sandbox that’s supposed to do super-private processing of passwords.

You’re just getting this steady feed of 16-byte data chunks coming from other people, and all you have to do is sit, and watch, and wait.


DOUGLAS.  So, short of waiting for the motherboard vendor to patch…

If you’re using a Mac, you don’t need to worry about this because there are ARM-based Macs and Intel-based Macs, but no AMD Macs, but what about Windows users with AMD processors, and maybe certain Linux users?


DUCK.  Your Linux distro may have a firmware microcode update that it will apply automatically for you.

And there is an essentially undocumented (or at best very poorly documented) AMD feature, a special command you can give to the chip via what are known as MSRs, or model-specific registers.

They’re like configuration-setting tools for each particular round of chips.

There is a setting you can make which apparently immunises your chip against this bug, so you can apply that.

There are commands to do this for Linux and the BSDs, but I’m not aware of similar commands on Windows, unfortunately.

Messing with the model-specific CPU registers [MSRs] can be done on Windows, but generally speaking, you need a kernel driver.

And that typically means getting it from some unknown third party, compiling it yourself, installing it, turning driver signing off…

…so only do that if you absolutely need to, and you absolutely know what you’re doing.

If you’re really desperate on Windows, and you have an AMD Zen 2 processor, I think… (I haven’t tried it because I don’t have a suitable computer at hand for my experiments.)


DOUGLAS.  You should expense one. [LAUGHS]

This is work-related!


DUCK.  You could probably, if you download and install WinDbg [pronounced “windbag”], the Microsoft Debugger…

…that allows you to enable local kernel debugging, connect to your own kernel, and fiddle with model-specific registers [DRAMATIC VOICE] *at your own peril*.

And, of course, if you’re using OpenBSD, from what I hear, good old Theo [de Raadt] has said, “You know what, there is a mitigation; it’s turning on this special bit that stops the bug working. We’re going to make that default in OpenBSD, because our preference is to try to favour security even at the cost of performance.”

But for everyone else, you’re going to have to either wait until it’s fixed or do a little bit of micro-hacking, all on your own!


DOUGLAS.  Alright, very good.

We will keep an eye on this, mark my words.

And as the sun begins to set on our show for today, let’s hear from one of our readers over on Facebook.

This relates to the Apple story that talked about at the top of the show.

Anthony writes:


I remember, back in the day, when Apple users used to crow over the PC crowd about how Apple’s architecture was watertight and needed no security patching.


Paul, that begs an interesting question, because I think we revisit this at least annually.

What do we say to people who say that Apple’s so secure that they don’t need any security software, or they don’t need to worry about hacking, or malware, or any of that sort of stuff?


DUCK.  Well, usually we give a nice big friendly grin and we say, “Hey, does anyone remember those ads? I’m a PC/I’m a Mac. I’m a PC/I’m a Mac. How did that play out?” [LAUGHTER]


DOUGLAS.  Well said!

And thank you very much, Anthony, for writing that in.

If you have an interesting story, comment or question you’d like to submit, we’d love to read it on the podcast.

You can email tips@sophos.com, comment on any one of our articles, or you can hit us up on social: @nakedSecurity.

That’s our show for today; thanks very much for listening.

For Paul Ducklin, I’m Doug Aamoth, reminding you, until next time, to…


BOTH.  Stay secure!

[MUSICAL MODEM]


Zenbleed: How the quest for CPU performance could put your passwords at risk

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!)


go top