Spectre, Yet Again. Because We Know You Missed It…

Spectre and its cousin Meltdown have been with us since 2018, and one would think that we’ve heard everything there is to hear about these vulnerabilities. But, here we are, with another post about Spectre.

Why does Spectre keep making an appearance? The problem with Spectre is that the vulnerability is essentially so broad that it amounts to a category of vulnerabilities rather than just one single vulnerability.

New versions of Spectre keep emerging – we’ve reported early in 2021 how new Spectre exploit code appeared in a public repository, as well as on two CVEs that were logged due to that code.

And so, with this article, we address another new variant of Spectre. We’ll tell you how it works, including the debate around Intel’s response so far. We also cover the key points you need to think about in protecting your operations against Spectre in the broad as well as against the latest variant.

Content:

1. Spectre and Meltdown – a refresher
2. How does Spectre work?
3. What’s the story behind the latest Spectre variant…?
4. …And who’s supposed to fix it?
5. Intel says it’s not up to them
6. Is it just a matter of coding correctly?
7. How to protect your workload against Spectre

Spectre and Meltdown – a refresher

Today’s processors rely on complex efficiency algorithms to improve processor performance. One of these is speculative execution.

Simply explained, speculative execution is where a processor performs work it thinks an application may need – without knowing for sure whether this work will be needed. If it turns out the work was needed then the results are available faster, which speeds up the application. If not, the results are simply discarded.

In fact, speculative execution is an essential element of modern processors. But, as it turns out, speculative execution has unintended consequences, and that’s where Spectre comes into play. In 2018, a way in which malevolent actors can abuse speculative execution came to light and rapidly caused huge concern in the tech community.

HOW DOES SPECTRE WORK?

We won’t go into deep detail about how Spectre works,  this TechRepublic guide is a good start. Besides, every Spectre exploit works differently. But, in the broad, Spectre and related exploits manipulate processors into getting access to the “discarded” data of speculative execution which means a malevolent actor can indirectly get access to unauthorized data.

One “positive” about Spectre is that it is quite difficult to build a Spectre exploit – it is hard to try and design a speculative execution attack with the intent to steal something specific. Nonetheless, hackers can exploit Spectre-related vulnerabilities to try and siphon off data that may or may not turn out to be useful.

However, a worrying aspect of Spectre is that even encrypted data is vulnerable to a Spectre attack as this data may be captured in its unencrypted state while the data is being handled by the processor.

As more has become known about Meltdown and Spectre various patches have been released to mitigate the exploits that security experts knew about – even though no single patch could completely mitigate all Spectre-related vulnerabilities. Again, this is because Spectre relies essentially on a disadvantage of speculative execution rather than a bug as such.

WHAT’S THE STORY BEHIND THE LATEST SPECTRE VARIANT…?

Needless to say, another Spectre exploit emerged – this time in May 2021. You can read the full write-up from Ars Technica here, but let’s take a look at some of the key points nonetheless. First off – yes, it’s yet another new speculative execution exploit. It proves that the concerns raised by the tech community in 2018 were valid – Spectre is an open-ended threat that is not going to go away quickly.

This time, researchers from the University of Virginia found a new execution attack that sidesteps all of the mitigations released by Intel and AMD to date. The attack targets a buffer on the CPU that serves as a cache for “micro-ops” – simplified commands derived from the more complex instructions. Again, the micro-ops feature is used in the interest of efficiency so that programs can run faster.

In the paper, the team outlines how an attacker can use the micro-ops cache in a “side-channel” attack, in other words as a way to make observations about data stored in a computer system. By closely watching the behavior of the CPU the attacker can draw conclusions about data that would otherwise not be available to see.

Again, it is a relatively complicated exploit to construct – but the problem nonetheless exists and adds a new dimension to the Spectre drama to date.

…AND WHO’S SUPPOSED TO FIX IT?

The new Spectre exploit affects processors made by Intel and AMD as both depend on a similar processor instruction set. As of yet, AMD has not responded to the new vulnerability. Intel’s response has been noted with interest, however.

Previous Spectre exploits were mitigated via a mix of hardware patches from Intel and AMD, as well as operating system patches. Again, there is no single patch that can take care of all Spectre-related exploits, but individual exploits can be managed by patching – both on the hardware level and in software.

Spectre’s latest, variation, however, breaks all of these defenses. Naturally, we’re left wondering when a new patch will become available to fix Spectre.

INTEL SAYS IT’S NOT UP TO THEM

This time, as reported by multiple sources including Ars Technica and Threatpost, Intel is essentially suggesting that no patch will be released for the latest Spectre exploit. According to the company, good practice when developing software is all it takes to ensure the latest Spectre exploit doesn’t pose a risk.

The company told Threatpost:

“Intel reviewed the report and informed researchers that existing mitigations were not being bypassed and that this scenario is addressed in our secure coding guidance. Software following our guidance already have protections against incidental channels including the uop cache incidental channel. No new mitigations or guidance are needed.”

Of course, nobody will argue against coding good practice – secure coding can limit or negate the impact of many vulnerabilities and produces more secure software, full stop. One of the central points in Intel’s secure coding guidance is the use of constant-time programming, but it a technique that is challenging for programmers, while impacting performance.

IS IT JUST A MATTER OF CODING CORRECTLY?

The proof of concept code in the research paper does not adhere to the programming principles suggested by Intel, and Intel is therefore saying that it is not a new vulnerability at all – but an issue that can be avoided by simply programming correctly. One security researcher agreed, suggesting that the paper points to further cleaning up of programming practices – even if doing so implies a performance hit.

In response, the authors of the paper replied that the vulnerability lies in the CPU and therefore requires a microcode patch – which was what Intel provided to mitigate Spectre threats in the past.

The team also says that too much software in everyday use does not apply constant time programming and that they don’t expect this to change in the near future. Specifically, the authors of the paper pointed out that constant time programming is typically only used within special security routines in an application because of the overhead that the practice implies.

The debate continues, and at least for now, the lack of a patch leaves this Spectre vulnerability out there for an attacker to exploit – though no exploits have emerged so far.

HOW TO PROTECT YOUR WORKLOAD AGAINST SPECTRE

One of the frustrating problems with Spectre mitigations has always been the performance impact, because Spectre patches modify processor efficiency tools, such as speculative execution, to limit the opportunities for an exploit.

This recent article from The Register outlines the compromises involved in mitigating against Spectre vulnerabilities. It makes one crucial point too – whilst Spectre exploits are very serious in nature, relatively few real-world cases have emerged of a successful hack driven by a Spectre exploit. That mirrors what we said earlier in this article – it is difficult to engineer an attack based on the weaknesses of speculative execution.

That doesn’t mean that your organization can sit back and ignore Spectre and its growing family of exploits. Some Spectre patches have larger performance impacts than others – do your research, and strike a balance between patching against Spectre – and maintaining performance.

As we explained, there is no patch for the latest Spectre exploit. Depending on your workload, and whether you can change the code that drives your workload, you may want to follow the best practice suggested by Intel to protect your workload against attacks derived from the techniques outlined in this paper.

Most users won’t be able to do so, however. Your best option is to ensure you roll out any patches as soon as these are released, and automated live patching can help you to do that.

In the meantime – keep an eye on the threat landscape, and our blog. Chances are this is not the last time we will be writing about Spectre.