SPECTRE ATTACK

Spectre attacks involve inducing a victim to speculatively perform operations that would not occur during correct program execution and which leak the victim’s confidential information via a side-channel to the adversary. This paper describes practical attacks that combine methodology from side-channel attacks, fault attacks, and return-oriented programming that can read arbitrary memory from the victim’s process. More broadly, the paper shows that speculative execution implementations violate the security assumptions underpinning numerous software security mechanisms, including operating system process separation, containerization, just-in-time (JIT) compilation, and countermeasures to cache timing and side-channel attacks. These attacks represent a serious threat to actual systems since vulnerable speculative execution capabilities are found in microprocessors from Intel, AMD, and ARM that are used in billions of devices. While makeshift processor-specific countermeasures are possible in some cases, sound solutions will require fixes to processor designs as well as updates to instruction set architectures (ISAs) to give hardware architects and software developers a common understanding as to what computation state CPU implementations are (and are not) permitted to leak.

The Meltdown vulnerability appeared because modern CPUs can execute instructions out of order. This is a very convenient feature that does accelerate code processing, but in some cases, the CPU happens to process code prone to error, code that shouldn’t be executed at all. That is, first the code is executed by the CPU, and only then does it become apparent that the operation cannot be completed — such situations happen exactly because instructions are executed out of order.

The Spectre vulnerability is similar to Meltdown, but although it’s also related to CPU computing acceleration, it stems from modern CPUs’ branch prediction feature. In essence, a CPU is able to predict, with a certain amount of accuracy, that because action B normally follows action A, it can execute action B before the results of A have become clear. If the guess was right, and action B does follow, everything’s good — and if the results of A indicate that the CPU should have completed action С instead of B, the CPU will just abandon the B branch and switch to another one where it has to complete action C.The branch predictor being trainable, in most cases it remembers the action sequence patterns, therefore really improving CPU performance (if B followed A several times, the CPU logically assumes that in a given situation it will have to do B after A as well). And yet mispredictions do happen (sometimes C comes along instead of B, although the branch predictor remembers full well that A is normally followed by B).

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.

Two Common Vulnerabilities and Exposures IDs related to Spectre, CVE-2017-5753 (bounds check bypass, Spectre-V1, Spectre 1.0) and CVE-2017-5715 (branch target injection, Spectre-V2), have been issued. JIT engines used for JavaScript were found to be vulnerable. A website can read data stored in the browser for another website, or the browser’s memory itself.

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.

Mechanism

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:

1. 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.
2. 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.
3. Thirdly, the paper synthesizes the results with return-oriented programming exploits and other principles with a simple example program and a JavaScript snippet run under a sandboxing browser; in both cases, the entire address space of the victim process (i.e. the contents of a running program) is shown to be readable by simply exploiting speculative execution of conditional branches in code generated by a stock compiler or the JavaScript machinery present in an existing browser. The basic idea is to search existing code for places where speculation touches upon otherwise inaccessible data, manipulate the processor into a state where speculative execution has to touch that data, and then time the side effect of the processor is faster if its by-now-prepared prefetch machinery indeed did load a cache line.
4. 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.”

Impact

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.^{[63][64][65][66]} 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.

Prevention

1. 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.
2. 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.
3. 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.
4. 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.
5. 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.