Spectre is a vulnerability that affects modern microprocessors that perform branch prediction. On most processors, the speculative execution resulting from a branch misprediction may leave observable side effects that may reveal private data to attackers. For example, if the pattern of memory accesses performed by such speculative execution depends on private data, the resulting state of the data cache constitutes a side channel through which an attacker may be able to extract information about the private data using a timing attack.
On 15 March 2018, Intel reported that it will redesign its CPUs (performance losses to be determined) to help protect against the Spectre and related Meltdown vulnerabilities (especially, Spectre variant 2 and Meltdown, but not Spectre variant 1), and expects to release the newly redesigned processors later in 2018. On 8 October 2018, Intel is reported to have added hardware and firmware mitigations regarding Spectre and Meltdown vulnerabilities to its latest processors. On 18 October 2018, MIT researchers suggested a new mitigation approach, called DAWG (Dynamically Allocated Way Guard), which may promise better security without compromising performance.
Spectre is a vulnerability that tricks a program into accessing arbitrary locations in the program’s memory space. An attacker may read the content of accessed memory, and thus potentially obtain sensitive data. Instead of a single easy-to-fix vulnerability, the Spectre white paper describes a whole class of potential vulnerabilities. They are all based on exploiting side effects of speculative execution, a common means of hiding memory latency and so speeding up execution in modern microprocessors. In particular, Spectre centers on branch prediction, which is a special case of speculative execution. Unlike the related Meltdown vulnerability disclosed at the same time, Spectre does not rely on a specific feature of a single processor’s memory management and protection system but is a more generalized idea.
The starting point of the white paper is that of a side-channel timing attack applied to the branch prediction machinery of modern out-of-order executing microprocessors. While at the architectural level documented in processor data books, any results of misprediction are specified to be discarded after the fact, the resulting speculative execution may still leave around side effects, like loaded cache lines. These can then affect the so-called non-functional aspects of the computing environment later on. If such side effects – including but not limited to memory access timing – are visible to a malicious program, and can be engineered to depend on sensitive data held by the victim process, then these side effects can result in those sensitive data becoming discernible. This can happen despite the formal architecture-level security arrangements working as designed; in this case, lower, microarchitecture-level optimizations to code execution [can] leak information not essential to the correctness of normal program execution.
The Spectre paper displays the attack in four essential steps:
- First, it shows that branch prediction logic in modern processors can be trained to reliably hit or miss based on the internal workings of a malicious program.
- It then goes on to show that the subsequent difference between cache hits and misses can be reliably timed so that what should have been a simple non-functional difference can, in fact, be subverted into a covert channel which extracts information from an unrelated process’s inner workings.
- Finally, the paper concludes by generalizing the attack to any non-functional state of the victim process. It briefly discusses even such highly non-obvious non-functional effects as bus arbitration latency.
The basic difference between Spectre and Meltdown is that Spectre can be used to manipulate a process into revealing its own data. On the other hand, Meltdown can be used to read privileged memory in a process’s address space which even the process itself would normally be unable to access (on some unprotected OSes this includes data belonging to the kernel or other processes).
The Meltdown paper distinguishes the two vulnerabilities thus: “Meltdown is distinct from the Spectre Attacks in several ways, notably that Spectre requires tailoring to the victim process’s software environment, but applies more broadly to CPUs and is not mitigated by KAISER.”
As of 2018, almost every computer system is affected by Spectre, including desktops, laptops, and mobile devices. Specifically, Spectre has been shown to work on Intel, AMD, ARM-based, and IBM processors. Intel responded to the reported security vulnerabilities with an official statement. AMD originally acknowledged vulnerability to one of the Spectre variants (GPZ variant 1) but stated that vulnerability to another (GPZ variant 2) had not been demonstrated on AMD processors, claiming it posed a “near zero risk of exploitation” due to differences in AMD architecture. In an update nine days later, AMD said that “GPZ Variant 2…is applicable to AMD processors” and defined upcoming steps to mitigate the threat. Several sources took AMD’s news of the vulnerability to GPZ variant 2 as a change from AMD’s prior claim, though AMD maintained that their position had not changed.
Researchers have indicated that the Spectre vulnerability can possibly affect some Intel, AMD, and ARM processors. Specifically, processors with speculative execution are affected by these vulnerabilities.ARM has reported that the majority of their processors are not vulnerable, and published a list of the specific processors that are affected by the Spectre vulnerability: Cortex-R7, Cortex-R8, Cortex-A8, Cortex-A9, Cortex-A15, Cortex-A17, Cortex-A57, Cortex-A72, Cortex-A73, and ARM Cortex-A75 cores. Other manufacturers’ custom CPU cores implementing the ARM instruction set, such as those found in newer members of the Apple A-series processors, have also been reported to be vulnerable. Spectre has the potential of having a greater impact on cloud providers than Meltdown. Whereas Meltdown allows unauthorized applications to read from privileged memory to obtain sensitive data from processes running on the same cloud server, Spectre can allow malicious programs to induce a hypervisor to transmit the data to a guest system running on top of it.
- Create a detailed inventory: Nearly every modern IT system will be affected to some extent. The starting point for security leaders must be to inventory all affected systems.
- Develop and prioritize remediation efforts: The vulnerabilities are not remotely exploitable. A successful attack requires the attacker to execute code on the system. Whitelisting and application controls on all systems will reduce the risk of unknown code execution.
- Recognize that patches are not always the right answer: Information security leaders must be prepared for scenarios in which a patch is not a solution. There will be a lack of patches for older systems. Patches might also fail because the impact on performance is not offset by the reduction in risks, such as with network and storage controllers.
- Be diligent about hygiene: For systems that are not patched or only partially patched, multiple mitigating controls can reduce risk. “The single most important issue to address is restricting the ability to place untrusted/unknown code onto the device. By doing this, we significantly reduce the risk, because attacks require local code execution — for Spectre and Meltdown — and any future attacks,” says MacDonald.
- Plan for the future, not the past: This is not the last we will see of these issues. The underlying exploitable implementation is still present and will remain so for years to come. Further research on this design flaw — involving speculative execution to discover new types of attacks— is expected and will likely require additional patches for hypervisors, OSs, browsers and firmware upgrades during the next several years.