Superbugs

The year 2018 began with a disaster for IT: We learned that most processors sold in the last 15 years come with two blatant bugs that make our systems vulnerable. The vulnerabilities, named Meltdown and Spectre, mainly affect CPUs of the market leader Intel, but related problems are also present in Apple, AMD, PowerPC, and ARM64 processors. (To the relief of makers around the world, the all-clear has been issued for all Raspberry Pi models.)

These security gaps, which are largely a result of the race for increasingly faster computers, will persist for a very long time and can only be completely eliminated with a new generation of CPUs – probably years in the future. Kernel developers will have to deal with the vulnerabilities that are opening up on PCs, smartphones, and even cloud service for a long time to come. With smartphones and tablets, only owners of currently supported devices can hope to eliminate the vulnerabilities; older devices remain unprotected.

In addition to the vulnerabilities that became known in January, security researchers published further attack scenarios [1] on February 14th. The previous software patches probably also cover these new attack vectors, but for Intel, this means that the changes to the CPU blueprints developed so far must be scrapped, and the engineers have to go back to the drawing board.

Intel Stonewalling

In the Spring and Summer of 2017, two research teams at Google and the University of Graz found alarming indications that volatile data such as passwords and other confidential data can be read from the memory of almost all current CPUs. The procedure requires in-depth knowledge and suitable tools. Potential perpetrators are therefore primarily government organizations and well-positioned cybercriminals.

Intel, ARM, and AMD were first informed about the gaps by Google researchers on June 1, 2017. It seems logical that a company first has to check such information internally. However, the fact that Intel sold faulty CPUs for half a year without informing customers is highly questionable and is already the basis for more than 30 individual and collective lawsuits in the USA.

In other respects also, Intel repeatedly gives the impression that the company is more interested in the share value than in the customers. The fact that Intel CEO Brian Krzanich sold a good portion of his 495,000 Intel shares well in advance of the announcement of the gap seems particularly sensitive. He only kept the shareholding that he had to have, according to the company regulations, in order not to lose his job.

So much for the bare facts. Home users can take comfort in the fact that attackers can only exploit these vulnerabilities at great expense. But that doesn't make things any better, especially given the inglorious approach of the lawyers and business economists who were determining the company's reaction. The strategy seemed to be first keep quiet, then deny for as long as possible, and finally fend off complaints if denial is no longer possible.

At the same time, the company had its developers throw together new microcode [2], which it then had to withdraw promptly. For Linux, the main burden of containment fell to the kernel developers. In the middle of the Linux 4.15 development cycle over the holidays at the end of the year, they were surprised by the dilemma that, in contrast to what Intel had intended, became public before 9th January. The kernel maintainers then erupted into hectic activity as they tried to mitigate the consequences of a catastrophe for which they themselves were not responsible. This effort pushed some developers to the brink of their capacity.

Linus Torvalds, master of the kernel, had sharp words for Intel's behavior and the company's unsuitable repair attempts [3]: He called Intel's hasty repair attempts "absolute rubbish" and "completely insane." Kernel developer Greg Kroah-Hartman stressed that Intel's repair attempts were a prime example of how not to deal with the kernel development community. The gaps even caused a new virtual directory to appear in the kernel tree at /sys/devices/system/cpu/vulnerabilities/ (Figure 1).

Figure 1: A new virtual directory lists the measures taken against the Meltdown and Spectre attacks.

Speculative Execution

Meltdown and Spectre attack scenarios exploit certain mechanisms in modern processor architectures. They are particularly aimed at out-of-order execution [4], which accelerates modern processors (Figure 2). The technique speculatively executes instructions, so that the processor has already loaded the required instruction when it needs it and does not have to wait to painstakingly access memory.

Figure 2: In the case of out-of-order command execution, the CPU speculatively executes several possible commands, one of which it actually implements, while it discards the others. (Image: Sputniktilt/Michael Kleine, commons.wikimedia.org, CC-BY-SA 2.0)

In some cases, the existence of this speculative data allows a capable attacker to access the kernel memory from user space. In this way, an attacker can potentially access all data that the machine is currently storing in memory, including passwords, security certificates, and other security-relevant data.

Out-of-order execution changes the system state at certain points, even if the CPU rejects the result of speculative execution. With appropriate software, the attacker can thus cause the attacked process to speculatively execute injected instructions.

The vulnerabilities have given rise to three different attack scenarios, known as Meltdown, Spectre v1, and Spectre v2. In general, because of actions taken by the kernel developers, Linux users were protected earlier and in a better way than Windows users. Linux users also have an edge when it comes to countermeasures taken by chip manufacturers: In many distributions, you directly receive the patches embedded in microcode as installable packages. Windows users have to wait far longer because the manufacturers first hand over the patches to the OEMs, who then have to adapt them to the hardware; only then can they pass the changes on to the customers as BIOS or firmware updates.

The microcode installed under Linux as a package is loaded each time the computer is started, which removes the need for a BIOS update on Linux computers. However, the microcode itself is proprietary software, so you have to unlock the contrib and nonfree repositories if you are installing on an all-free distro such as Debian.

Clarified

An Intel paper from February 11, 2018 provides clarity for the first time regarding which processors will need new microcode and what is the current state of development [5]. All information in this document refers to Spectre v2. Closing this gap requires a kernel patch as well as new microcode from Intel. In the paper, Intel for the first time also lists older CPUs that were launched about ten years ago. Ivy Bridge, Sandy Bridge, Penryn, Wolfdale, and Yorkfield will now also be receiving microcode updates.

Intel released a new microcode version in early February, which was initially only stable for Skylake processors. At the time this article was written, microcode had not yet reached the Linux distributions; according to Intel, versions for further processors were still in beta testing at that time.

The fundamental difference between Spectre and Meltdown is that Spectre manipulates a process such that the process reveals its own data, whereas Meltdown can read privileged memory in the address space of a process that even the process itself normally cannot access.