Cyber threats come and go, but some threats leave a lasting imprint due to their impact. Think of Spectre and the closely related Meltdown, for example, two of the most widely covered vulnerabilities in recent memory.

It is of course frustrating when a cyber threat simply refuses to go away, and even worse when it is a highly prominent vulnerability. That’s turning out to be the case with Spectre, one of the most dangerous exploits of recent times. While patched systems are protected against Spectre, the nature of Spectre patches and the resulting impact on performance means that a large number of systems have not been patched..

That leaves many key systems vulnerable to Spectre. Worse, a new publicly accessible exploit for Spectre has just been published. As it turns out, Spectre is not quite dead. Let’s take a look.

Content

• Introduction to Spectre
• How does the Spectre vulnerability work?
• Why Spectre patches caused complications
• Performance problems with Spectre CPU patches
• OS patches also impacted performance
• The result: delayed patching
• What is VirusTotal DB?
• The discovery of the code
• How the public Spectre exploit affects the IT world
• Guarding against the public Spectre exploit

Introduction to Spectre

Spectre is in fact one of a trio of vulnerabilities that are related. There are two versions of Spectre, while the third vulnerability is called Meltdown. At the time, security researchers called these vulnerabilities catastrophic. Thankfully, adequate patches were rapidly released – but there was a complication.

How does the Spectre vulnerability work?

First, let’s take a look at how Spectre works. Vulnerabilities are often located in software: errors or oversights in application or operating system code. The Spectre vulnerabilities are, however, hardware vulnerabilities, and are located in hardware that is used in every computer around the world: the central processing unit, or CPU.

At the time these were discovered, the two Spectre vulnerabilities and Meltdown affected almost every CPU in use – from Intel chips to AMD and Arm processors; though the degree to which a CPU was vulnerable depended on the CPU vendor and the architecture.

The vulnerabilities come down to a hardware flaw in the way processors are designed, and is essentially a silicon-level problem.

Without going into too much technical detail, modern processors deal with CPU instructions in complicated ways – executing instructions out of order and speculatively, for example. Processors do this in order to make instruction execution more efficient – in other words, to execute instructions faster.

Spectre and its cousin Meltdown rely on flaws in the way instruction execution is handled in modern-day processors. By manipulating these flaws, a hacker that exploits the vulnerability is able to read arbitrary memory space and thereby obtain sensitive data.

Why Spectre patches caused complications

Spectre is a hardware vulnerability and CPU vendors including Intel and AMD released patches to mitigate the risks of Spectre. The patch was essentially a small bit of software that updated the CPU microcode.

CPU microcode includes the list of instructions available to the processor, and the procedures followed when an instruction has multiple steps – which would also impact how execution efficiencies such as speculative and out-of-order execution was treated.

When a bug or vulnerability is found in a specific CPU functionality, a patch containing microcode can be issued by the manufacturer to either disable the instruction, make it have no function at all, or change the way the instruction is handled internally. It is the same hardware, but the CPU will perform slightly differently.

More recent editions of commonly used CPUs made design changes to be less vulnerable to Spectre and Meltdown, as vendors learned lessons from the trio of vulnerabilities.

Some users simply never ran the patches, as is always the problem with patching, so their CPU microcode was never updated. However, a larger problem soon emerged with the patches released to protect users against Spectre and Meltdown.

Performance problems with Spectre CPU patches

The changes to the CPU microcode that was included in the vendor patches often impacted the performance of CPUs and therefore the servers that use these CPUs, and in some cases, it did so to an unacceptable degree.

Because Spectre and Meltdown exploited flaws in the sophisticated technologies that make CPUs more efficient, it was difficult to develop patches that did not impact these efficiencies. When released, the patches from Intel, AMD and other processor vendors that protected against the vulnerabilities changed or limited some of these instruction execution efficiencies.

Performance problems rapidly emerged and affected all operating systems and most CPUs. This effect varied depending on the CPU in question, with some Intel chips affected more than AMD processors. In one analysis, hardware site ExtremeTech found during tests that Intel chips were affected five times more severely than AMD chips.

Microsoft also published an article covering the performance impact, pointing to a heavier impact on older CPUs compared to the later generations – the company suggested that some users will see a noticeable decrease in performance.

OS patches also impacted performance

The first route to mitigation against Spectre and its cousin was via a patch that updated the CPU microcode. However, operating system vendors also released patches in an attempt to protect against Meltdown and Spectre.

Just like the CPU patches, mitigations implemented in the operating system led to performance issues. In the OS the mitigation was achieved by changing the way the operating system and, by extension, the user software running on top of said operating system, translates its code into machine instructions. In other words, which CPU instructions it will use to perform its functions.

For example, in late 2018, it emerged that mitigation applied to a version of the Linux kernel caused some workloads to see a performance drop of as much as 50%. In this case, it was a mitigation called Single Thread Indirect Branch Predictors (STIBP), and the performance impact was so significant that Linus Torvalds himself intervened.

The result: delayed patching

The widely-published performance impact of Spectre patches quickly became a barrier to broad, consistent patching – a barrier above and beyond the problems companies have in consistently patching their machines even where no performance hit is implied.

Where workloads demanded certain performance levels, and even where efficiency was the only concern, sysadmins sometimes opted to not patch in case the patch causes serious performance and therefore reliability issues.

The result is that while Spectre and Meltdown are both known vulnerabilities, many systems out in the wild were never patched simply because users were concerned about performance problems. This is a relatively unique situation as in most cases system administrators would patch as effectively as practically possible to guard against security risks.

Despite the issues with patching, there was one relatively positive aspect about the Spectre vulnerabilities – since discovery, no publicly available exploit has been published for Spectre. Until now.

What is VirusTotal DB?

Accessibility to a public, published exploit of a vulnerability can make a vulnerability far more dangerous than it previously was. Unfortunately, in the case of Spectre, the first publicly available exploit has now emerged. It was recently published on a website called VirusTotal DB. First, let’s take a look at VirusTotal DB and what it is used for.

VirusTotal was originally developed in Spain, but is now under the auspices of Alphabet, the parent of Google. It’s essentially an aggregator, pulling together various online scan engines and anti-virus products. Users can upload files for checking – including to verify against false positives.

The website relies on a range of contributors, from anti-virus engines and website scanners through to user contributions. And it is in one of these contributions that a working exploit for Spectre was discovered.

The discovery of the code

In February 2021, an analyst discovered that in adding a contribution to VirusTotal, a user simultaneously uploaded a working exploit for Spectre that can be used on unpatched systems running Linux.

The code was part of a tool called Immunity Canvas. The application performs automatic penetration testing. That is, it tests systems against vulnerabilities to multiple exploits. The company had developed a working tool to test for this specific Spectre exploit.

But in contributing their code to VirusTotal, Immunity Canvas included the exploit code. After all, the test code can be used outside the original penetration testing tool and used independently with the appropriate modifications.

The code is not instantly usable: the party that wants to use it must be motivated enough to manipulate the code into a working exploit, but there is sufficient code in the VirusTotal contribution for a determined actor to build a working Spectre exploit.

How the public Spectre exploit affects the IT world

In theory, in a world where patches are applied consistently, the now-public exploit for Spectre would pose no danger. Of course, as we explained earlier in this article, the problem lies in the fact that the performance hit generated by some Spectre patches means that some users have opted not to patch their systems against Spectre.

This performance hit can be high. Understandably, some enterprises may make the analysis that the performance hit is simply much worse than the risk or impact of a security breach as the performance hit would require a significant expansion in hardware to compensate.

With this public exploit this calculation has changed – the risks of an attack is much higher with the exploit code now in the wild. Notably, the systems vulnerable to Spectre are typically still within their typical useful lifecycle.

There is another possibility too that should concern users of systems that are not patched against Spectre. The Spectre and Meltdown vulnerabilities are all closely related. Now that one vulnerability has a published exploit, a working path exists to exploit the other vulnerabilities – and a determined attacker may well take advantage of the opportunity.

It leads to a perfect storm of a publicly visible exploit alongside a significant number of unpatched systems. Sysadmins and enterprises that were trying to stay away from the mitigations on account of performance concerns now need to reconsider and apply them.

Should they continue to refuse to do so they must realize that they are risking attacks and breaches that could quickly escalate into very high costs.

Guarding against the public Spectre exploit

Spectre is a three-year-old extensively known and publicized vulnerability, which has had mitigations available for years. Few systems should be left unprotected. Yet the mitigations had a non-negligible performance impact on the systems that they are deployed to, and as such, sysadmins have been reluctant to apply them.

A publicly available Spectre exploit simply isn’t good news, but guarding against it should not be difficult. Patches have been released for hardware, and operating system vendors have also released effective patches. This public exploit will not work on a patched system.

Where systems have not been patched, users must now take steps to patch against Spectre and Meltdown – even if there is a potential performance hit. It really is as simple as that.

Now that a Spectre exploit is publicly available, the time to act has come – sysadmins must patch vulnerable systems against Spectre, and they must do so now – even if there is a performance impact. Where patching is challenging, sysadmins can make use of tools such as KernelCare to patch on the fly – without needing to reboot critical systems.