Spectre, a seemingly never ending menace to processors, is back in the limelight once again thanks to the Universal Read Gadget. First seen at the start of 2018, Spectre emerged alongside Meltdown as a major potential threat to people’s system security.
Meltdown and Spectre
Meltdown targeted Intel processors and required a malicious process running on the system to interact with it. Spectre could be launched from browsers via a script. As these threats were targeting hardware flaws in the CPU, they were difficult to address and required BIOS updates and some other things to ensure a safe online experience. As per our original blog:
The core issue stems from a design flaw that allows attackers access to memory contents from any device, be it desktop, smart phone, or cloud server, exposing passwords and other sensitive data. The flaw in question is tied to what is called speculative execution, which happens when a processor guesses the next operations to perform based on previously cached iterations.The Meltdown variant only impacts Intel CPUs, whereas the second set of Spectre variants impacts all vendors of CPUs with support of speculative execution. This includes most CPUs produced during the last 15 years from Intel, AMD, ARM, and IBM.
This is not a great situation for everyone to suddenly find themselves in. Manufacturers were caught on the backfoot and customers rightly demanded a solution.
If this is the part where you’re thinking, “What caused this again?” then you’re in luck.
Speculative patching woes
The issues came from something called “speculative execution.” As we said in this follow up blog about patching difficulties:
Speculative execution is an effective optimization technique used by most modern processors to determine where code is likely to go next. Hence, when it encounters a conditional branch instruction, the processor makes a guess for which branch might be executed based on the previous branches’ processing history. It then speculatively executes instructions until the original condition is known to be true or false. If the latter, the pending instructions are abandoned, and the processor reloads its state based on what it determines to be the correct execution path.The issue with this behaviour and the way it’s currently implemented in numerous chips is that when the processor makes a wrong guess, it has already speculatively executed a few instructions. These are saved in cache, even if they are from the invalid branch. Spectre and Meltdown take advantage of this situation by comparing the loading time of two variables, determining if one has been loaded during the speculative execution, and deducing its value.
Four variants existed across Spectre and Meltdown, with Intel, IBM, ARM, and AMD being snagged by Spectre and “just” Intel being caught up by Meltdown.
The vulnerabilities impacting CPUs (central processing units) made it a tricky thing to fix. Software alterations could cause performance snags, and hardware fixes could be even more complicated. A working group was formed to try and thrash out the incredibly complicated details of how this issue would be tackled.
In January 2018, researchers stressed the only real way to solve Spectre was redesigning computer hardware from the ground up. This is no easy task. Replace everything, or suffer the possible performance hit from any software fixes. Fairly complex patching nightmares abound, with operating systems, pre/post Skylake CPUs, and more needing tweaks or wholesale changes.
Additional complications
It wasn’t long before scams started capitalising on the rush to patch. Now people suddenly had to deal with unrelated fakes, malware, and phishes on top of actual Meltdown/Spectre threats.
Alongside the previously mentioned scams, fake websites started to pop up, too. Typically they claimed to be an official government portals, or plain old download sites offering up a fix. They might also make use of SSL, because displaying a padlock is now a common trick of phishers. That’s a false sense of security—just because there’s a padlock, doesn’t mean it’s a safe site. All it means is the data on it is encrypted. Beyond that, you’re on your own.
The site in our example offered up a zipfile. Contained within was SmokeLoader, well known for attempting to grab additional malicious downloads.
Click to enlarge
Eventually, the furore died down and people slowly forgot about Spectre. It’d pop up again in occasional news articles, but for the most part, people treated it as out of sight, out of mind.
Which brings us to last week’s news.
Spectre: What happened now?
What happened now is a reiteration of the “it’s not safe yet” message. The threat is mostly the same, and a lot of people may not need to worry about this. However, as The Register notes, the problem hasn’t gone away and some developers will need to keep it in mind.
Google has released a paper titled, unsurprisingly enough, “Spectre is here to stay: An analysis of side-channels and speculative execution.”
The Google paper
First thing’s first: It’s complicated, and you can read the full paper [PDF] here.
There’s a lot of moving parts to this, and frankly nobody should be expected to understand everything in it unless they’re working in or around this in some capacity. Some of this has already been mentioned, but it’s already about 700 words or so ago so a short recap may be handy:
- Side channels are bad. Your computer may be doing a bunch of secure tasks, keeping your data safe. All those bits and pieces of hardware, however, are doing all sorts of things to make those secure processes happen. Side channel attacks come at the otherwise secure data from another angle, in the realm of the mechanical. Sound, power consumption, timing between events, electromagnetic leaks, cameras, and more. All of these provide a means for a clever attacker to exploit this leaky side channel and grab data you’d rather they didn’t.
- They do this in Spectre’s case by exploiting speculative execution. Modern processors are big fans of speculative execution, given they make use of it extensively. It helps improve performance, by making guesses about what programs will do next and then abandoning if it turns out that doesn’t happen after all. Conversely, the retained paths are deployed and everything gets a nice speed boost. Those future potential possibilities is where Spectre comes in.
- As the paper says, “computations that should never have happened…allow for information to be leaked” via Spectre. It allows the attacker to inject “dangerously speculative behaviour” into trusted code, or untrusted code typically subjected to safety checks. Both are done through triggering “ordinarily impossible computations” through specific manipulations of the processor’s shared micro-architectural states.
Everything is a bit speed versus security, and security lost out. The manufacturers realised too late that the speed/security tradeoff came with a hefty security price the moment Spectre arrived on the scene. Thinking bad actors couldn’t tamper with with speculative executions—or worse, not considering this in the first place—has turned
out to be a bit of a disaster.
The paper goes on to list that Intel, ARM, AMD, MIPS, IBM, and Oracle have all reported being affected. It’s also clear that:
Our paper shows these leaks are not only design flaws, but are in fact foundational, at the very base of theoretical computation.
This isn’t great. Nor is the fact that they estimate it’s probably more widely distributed than any security flaw in history, affecting “billions of CPUs in production across all device classes.”
Spectre: no exorcism due
The research paper asserts that Spectre is going to be around for a long time. Software-based techniques to ward off the threat will never quite remove the issue. They may ward off the threat but add a performance cost, with more layers of defence potentially making things too much of a drag to consider them beneficial.
The fixes end up being a mixed bag of trade-offs and performance hits, and Spectre is so variable and evasive that it quickly becomes impossible to pin down a 100 percent satisfactory solution. At this point, Google’s “Universal Read Gadget” wades in and makes everything worse.
What is the Universal Read Gadget?
A way to read data without permission that is for all intents and purposes unstoppable. When multiple vulnerabilities in current languages run on the CPU, it allows construction of said read gadget and that’s the real meat of Google’s research. Nobody is going to ditch speculative execution anytime soon, and nobody is going to magically come up with a way to solve the side channel issue, much less something like a Universal Read Gadget.
As the paper states,
We now believe that speculative vulnerabilities on today’s hardware defeat all language-enforced confidentiality with no known comprehensive software mitigations…as we have discovered that untrusted code can construct a universal read gadget to read all memory in the same address space through side-channels.
On the other hand, it’s clear we shouldn’t start panicking. It sounds bad, and it is bad, but it’s unlikely anyone is exploiting you using these techniques. Of course, unlikely doesn’t mean unfeasible, and this is why hardware and software organisations continue to wrestle with this particular genie.
The research paper stresses that the URG is very difficult to pull off.
The universal read gadget is not necessarily a straightforward construction. It requires detailed knowledge of the μ-architectural characteristics of the CPU and knowledge of the language implementation, whether that be a static compiler or a virtual machine. Additionally, the gadget might have particularly unusual performance and concurrency characteristics
Numerous scenarios will require different approaches, and it lists multiple instances where the gadget will potentially fail. In short, nobody is going to come along and Universal Read Gadget your computer. For now, much of this is at the theoretical stage. That doesn’t mean tech giants are becoming complacent however, and hardware and software organisations have a long road ahead to finally lay this spectre to rest.
