Spectre vulnerability: 4 years after discovery

Four years have passed since the first publication of the research on Spectre and Meltdown, hardware vulnerabilities in modern processors. Since then, researchers discovered several similar flaws, that are potentially capable of leaking confidential data. The researchers also showed examples of attacks using these vulnerabilities, although most of them are unlikely to be used in the wild. In this post we look at the state of these hardware issues today and on their potential use to attack businesses.

Several variants of Spectre

The original August 2018 announcement revealed three vulnerabilities: Spectre v1 and v2, and Meltdown. Those vulnerabilities have several common features:

• Their exploitation usually involves the execution of malicious code on a vulnerable system, albeit with low privileges. The most dangerous option is an attack through a browser when visiting an “infected” web page.
• Practical exploitation requires a number of conditions, in particular, the code of the attacked application must allow data leakage, have a so-called “gadget,” access to which makes the attack possible.
• The data leak itself occurs through side channels. Because of this, the speed of the data leak is extremely low.
• A successful attack may leave no traces of unauthorized data access at all.

The last argument is precisely what aroused particular interest in this seemingly theoretical scientific work. In all cases, researchers exploited the branch prediction system. This mechanism was introduced more than 20 years ago, it allows you to speed up performance by executing a set of instructions even before an explicit request for their execution from the program. If the prediction was correct, the processor resources will be used more efficiently. If the prediction is wrong, the calculations are just discarded.

POC for the Spectre v1 showed that the processor will read data that should be inaccessible by the program. It is stored in the cache and can be retrieved from there through side channels. This mechanism was considered safe, because that erroneously read “secret” was not transmitted to the program. But researchers have found ways to indirectly read that data.

After the publication of work on Spectre and Meltdown, several more similar vulnerabilities were discovered. Researchers continue to look for new methods for extracting secret data by exploiting the vulnerabilities of processors. Intel’s summary table lists more than 20 of these issues, in addition to the original three.

How to fight Spectre

Theoretically there are three ways to make a processor vulnerability less exploitable: vendors can issue a microcode update for existing processors, they can modify new CPUs, or try to solve the problem through the software updates. Often true mitigation requires a combination of firmware and software updates. The new microcode covering some of the vulnerabilities has been available for Intel processors since the 2013 Haswell generation. Hardware solutions were first implemented in the eighth generation of Intel processors, as well as in AMD’s Zen 2 CPUs.

Software solutions can be quite tricky: as an example, you can look at the possible modifications in the Linux kernel against Spectre v1 and v2. A wide range of measures were discussed, depending on the goals and objectives of a particular system, including the complete disabling of speculative code execution with serious consequences for CPU performance.

For most organizations whose business model depends on the performance of a large fleet of servers such performance drop will be the most noticeable impact of anti-Spectre measures. A relatively recent benchmark on the Phoronix website, which examines the performance of various server applications, shows a 25% performance decrease on average when all anti-Spectre precautions in the Linux OS are enabled.

Practical attacks and proofs of concept

Despite the large number of attack types, the threat of data theft using Spectre is still theoretical. Although each research contains some code that demonstrates the leak, this does not mean that this code can be used against a real system. The typical limitations of these demos or proof of concept are as follows:

• They demonstrate a random data leak. It may not have a practical value, it is just random information that the attacker did not previously have access to.
• Researchers created ideal conditions for the attack. For example, they had an unlimited access to the system. In this case, it is not necessary to use complex data exfiltration methods.
• It demonstrates a real data breach, but in highly unlikely conditions.

The most impressive theoretical work (in terms of possible consequences) is the NetSpectre attack. The researchers managed to demonstrate remote exploitation with data exfiltration at a speed of 15 to 60 bits per hour. The limitations of the attack are clear: low data transmission rate, exfiltrated data contains a huge amount of junk traffic, plus vulnerable code on the attacked server “in the right place” for success.

Two practical attacks, as close as possible to ITW conditions, were shown last year. In March, Google showed a leaky.page concept: a web page that can extract data from the RAM. In September, a Spook.js attack on the latest (at the time of research) version Google Chrome (92) with Spectre protection (isolation of web pages in separate browser processes) was demonstrated. This method allowed real data theft: researchers accessed credentials for a social network, password manager data, and an image uploaded by a user to a private cloud. But in all that cases, the successful data lead required to have an “infected” page located on the same domain. For example, stealing a Tumblr password involves uploading malicious Javascript code to another page on the same social network.

So how dangerous is the threat?

The Spook.js was neutralized with a software patch for the Google Chrome browser. Therefore, at this moment, there is no immediate threat of exploitation of Spectre vulnerabilities in real conditions. All known attacks are extremely complex and require the highest skill of the attacker.

Most realistic proofs of concept were patched, and even without patches, their exploitation requires a large set of conditions. Even though media reports about real “Spectre exploits” have not been confirmed, security vendors have added tools to detect known attacks just in case, so most likely existing malware detection mechanisms can help to protect your company.

However, we should not completely ignore the Spectre: it is important that research continues. There is a small chance that over time, the “worst-case scenario” will be discovered: an attack that does not require installation of malware that allows to data leak that leaves no trace.

Theoretically it is possible to conduct a targeted attack using hardware vulnerabilities if the value of the stolen data justifies it. Protection against such risks requires serious investments in identifying potential attack vectors, following the recommendations of OS developers, or implementing protection even at the cost of a serious performance drop. But for most, even large companies, it is enough to rely on the software and operating system developers, processor manufacturers, and security solutions.