Spectre (security vulnerability)

From Infogalactic: the planetary knowledge core
Jump to: navigation, search

File:Spectre with text.svg
A logo created for the vulnerability, featuring a ghost with a branch

Spectre is a vulnerability that affects modern microprocessors that perform branch prediction.[1][2][3] 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.[4][5][6]

Two Common Vulnerabilities and Exposures IDs related to Spectre, CVE-Lua error in package.lua at line 80: module 'strict' not found. (bounds check bypass, Spectre-V1, Spectre 1.0) and CVE-Lua error in package.lua at line 80: module 'strict' not found. (branch target injection, Spectre-V2), have been issued.[7] 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.[8]

On March 15, 2018, Intel reported that it will redesign its CPU processors (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.[9][10][11][12]

History

In 2002 and 2003 Yukiyasu Tsunoo and colleagues from NEC showed how to attack MISTY and DES respectively. In 2005, Daniel Bernstein from the University of Illinois reported an extraction of an OpenSSL AES key via a cache timing attack, and Colin Percival had a working attack on the OpenSSL RSA key using the Intel processor's cache. In 2013 Yuval Yarom and Katrina Falkner from the University of Adelaide showed how measuring the access time to data lets a spy application guess if the information was read from the cache, or not. If it was read from the cache the access time was very short, and the data read could contain the private key of encryption algorithms. This technique was used to successfully attack GnuPG, AES and other cryptographic implementations[13][14][15][16][17][18] In January 2017, Anders Fogh gave a presentation at the Ruhruniversität Bochum about automatically finding covert channels, especially on processors with a pipeline used by more than one processor core.[19]

Spectre was discovered independently by Jann Horn from Google's Project Zero and Paul Kocher in collaboration with Daniel Genkin, Mike Hamburg, Moritz Lipp and Yuval Yarom.[when?] Microsoft Vulnerability Research extended it to browsers' JavaScript JIT engines.[4][20] It was made public in conjunction with another vulnerability, Meltdown, on January 3, 2018, after the affected hardware vendors had already been made aware of the issue on June 1, 2017.[21] The vulnerability was called "Spectre" because it "is based on the root cause, speculative execution. As it is not easy to fix, it will haunt us for quite some time."[22]

On January 28, 2018, it was reported that Intel shared news of the Meltdown and Spectre security vulnerabilities with Chinese technology companies, before notifying the U.S. government of the flaws.[23]

On January 29, 2018, Microsoft was reported to have released a Windows update that disables the problematic microcode fix (causing possible reboots, stability and data loss/corruption problems) issued earlier by Intel for the Spectre Variant 2 attack.[24][25] Concerns about installing the new Microsoft patch have been reported.[26]

On May 3, 2018, eight additional Spectre-class flaws provisionally named Spectre-NG were reported affecting Intel and possibly AMD and ARM processors. Intel reported that they are preparing new patches to mitigate these flaws.[27][28][29][30] Affected are all Core-i processors and Xeon derivates since Nehalem (2010) and Atom-based processors since 2013.[31] Intel has postponed releasing microcode updates, with the date slipping to July 10, 2018.[32][31]

On May 21, 2018, Intel published information on the first two Spectre-NG class side-channel vulnerabilities CVE-Lua error in package.lua at line 80: module 'strict' not found. (Rogue System Register Read, Variant 3a) and CVE-Lua error in package.lua at line 80: module 'strict' not found. (Speculative Store Bypass, Variant 4),[33][34] both also referred to as Intel SA-00115 and HP PSR-2018-0074.

According to Amazon Deutschland, Cyberus Technology, SYSGO, and Colin Percival (FreeBSD), Intel has revealed details on the third Spectre-NG variant CVE-Lua error in package.lua at line 80: module 'strict' not found. (Lazy FP State Restore, Intel SA-00145) on June 13, 2018.[35][36][37][38] It is also known as Lazy FPU state leak (abbreviated "LazyFP") and "Spectre-NG 3".[37]

On July 10, 2018, Intel revealed details on another Spectre-NG class vulnerability called "Bounds Check Bypass Store" (BCBS) aka "Spectre 1.1" (CVE-Lua error in package.lua at line 80: module 'strict' not found.) allowing not only to read but also to write out of bounds.[39][40][41][42] Another variant named "Spectre 1.2" gets mentioned as well.[42]

In late July 2018 researchers at the universities of Saarland and California revealed ret2spec (aka "Spectre v5") and SpectreRSB, new types of code executation vulnerabilities using the Return Stack Buffer (RSB).[43][44][45]

At the end of July 2018, researchers at the University of Graz revealed "NetSpectre", a new type of remote attack similar to Spectre V1, but which does not need attacker-controlled code to be run on the target device at all.[46][47]

Detailed explanation

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[1] describes a whole class[48] 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,[49] 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[50] 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 annulled 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 extant 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 being 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."[51]

Remote exploitation

While Spectre is simpler to exploit with a compiled language such as C or C++ by locally executing machine code, it can also be remotely exploited by code hosted on remote malicious web pages, for example interpreted languages like JavaScript, which run locally using a web browser. The scripted malware would then have access to all the memory mapped to the address space of the running browser.[52]

The exploit using remote JavaScript follows a similar flow to that of a local machine code exploit: Flush Cache → Mistrain Branch Predictor → Timed Reads (tracking hit / miss).

The absence of the availability to use the clflush instruction (cache-line flush) in JavaScript requires an alternate approach. There are several automatic cache eviction policies which the CPU may choose, and we rely on being able to force that eviction for the exploit to work. It was found that using a second index on the large array, which was kept several iterations behind the first index, would cause the least recently used (LRU) policy to be used. This allows the exploit to effectively clear the cache just by doing incremental reads on a large dataset.

The branch predictor would then be mistrained by iterating over a very large dataset using bitwise operations for setting the index to in-range vales, and then using an out-of-bounds address for the final iteration.

A high-precision timer would then be required in order to determine if a set of reads led to a cache-hit or a cache-miss. While browsers like Chrome, Firefox, and Tor (based on Firefox) have placed restrictions on the resolution of timers (required in Spectre exploit to determine if cache hit/miss), at the time of authoring the white paper, the Spectre author was able to create a high-precision timer using the web worker feature of HTML5.

Careful coding and analysis of the machine code executed by the just-in-time compilation (JIT) compiler was required to ensure the cache-clearing and exploitive reads were not optimized-out.

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.[53][54][55] Intel responded to the reported security vulnerabilities with an official statement.[56] 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.[57][58][59]

Researchers have indicated that the Spectre vulnerability can possibly affect some Intel, AMD, and ARM processors.[60][61][62][63] Specifically, processors with speculative execution are affected with these vulnerabilities.[64]

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.[65] 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.[66]

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.[67]

Mitigation

Since Spectre represents a whole class of attacks, most likely, there cannot be a single patch for it.[3] While work is already being done to address special cases of the vulnerability, the original website devoted to Spectre and Meltdown states: "As [Spectre] is not easy to fix, it will haunt us for a long time."[4] At the same time, according to Dell: "No 'real-world' exploits of these vulnerabilities [ie, Meltdown and Spectre] have been reported to date [February 7, 2018], though researchers have produced proof-of-concepts."[68][69]

Several procedures to help protect home computers and related devices from the vulnerability have been published.[70][71][72][73] Spectre patches have been reported to significantly slow down performance, especially on older computers; on the newer eighth-generation Core platforms, benchmark performance drops of 2–14 percent have been measured.[74][5][75][76] On January 18, 2018, unwanted reboots, even for newer Intel chips, due to Meltdown and Spectre patches, were reported.

It has been suggested[77] that the cost of mitigation can be alleviated by processors which feature selective translation lookaside buffer (TLB) flushing, a feature which is called process-context identifier (PCID) under Intel 64 architecture, and under Alpha, an address space number (ASN). This is because selective flushing enables the TLB behavior crucial to the exploit to be isolated across processes, without constantly flushing the entire TLB – the primary reason for the cost of mitigation.[citation needed]

In March 2018, Intel announced that they had developed hardware fixes for Meltdown and Spectre-V2 only, but not Spectre-V1.[9][10][11] The vulnerabilities were mitigated by a new partitioning system that improves process and privilege-level separation.[12]

Summary of mitigations on Microsoft Windows[7][78][33][37][38]
Vulnerability CVE Exploit name Public vulnerability name Windows changes Firmware changes
Spectre 2017-5753 Variant 1 Bounds Check Bypass (BCB) Recompiling with a new compiler
Hardened browser to prevent exploit from JavaScript
No
Spectre 2017-5715 Variant 2 Branch Target Injection (BTI) New CPU instructions eliminating branch speculation Yes
Meltdown 2017-5754 Variant 3 Rogue Data Cache Load (RDCL) Isolate kernel and user mode page tables No
Spectre-NG 2018-3640 Variant 3a Rogue System Register Read (RSRE) Yes
Spectre-NG 2018-3639 Variant 4 Speculative Store Bypass (SSB) Yes
Spectre-NG 2018-3665 Lazy FP State Restore
Spectre-NG 2018-3693 Variant 1.1 Bounds Check Bypass Store (BCBS)
Spectre Variant 1.2 Read-only protection bypass (RPB)
SpectreRSB Return Mispredict

Particular software

Be as it may, several procedures to help protect home computers and related devices from the vulnerability have been published.[70][71][72][73]

Initial mitigation efforts were not entirely without incident. At first, Spectre patches were reported to significantly slow down performance, especially on older computers. On the newer eighth generation Core platforms, benchmark performance drops of 2–14 percent were measured.[74] On January 18, 2018, unwanted reboots were reported even for newer Intel chips.[79]

Since exploitation of Spectre through JavaScript embedded in websites is possible,[1] Chrome 64 will include mitigations against the attack by default. Chrome 63 users can manually mitigate the attack by enabling the Site Isolation feature (chrome://flags#enable-site-per-process).[80]

As of Firefox 57.0.4, Mozilla is reducing the resolution of JavaScript timers to help prevent timing attacks, with additional work on time-fuzzing techniques planned for future releases.[20][81]

General approaches and controversy

On January 4, 2018, Google detailed a new technique on their security blog called "Retpoline" (return trampoline)[82] which can overcome the Spectre vulnerability with a negligible amount of processor overhead. It involves compiler-level steering of indirect branches towards a different target that does not result in a vulnerable speculative out-of-order execution taking place.[83][84] While it was developed for the x86 instruction set, Google engineers believe the technique is transferable to other processors as well.[85]

On January 25, 2018, the current status and possible future considerations in solving the Meltdown and Spectre vulnerabilities were presented.[86]

When Intel announced that Spectre mitigation can be switched on as a "security feature" instead of being a bug, Linux creator Linus Torvalds called the patches "complete and utter garbage".[87] Ingo Molnár then suggested the use of function tracing machinery in the Linux kernel to fix Spectre without Indirect Branch Restricted Speculation (IBRS) microcode support. This would, as a result, only have a performance impact on processors based on Intel Skylake and newer architecture.[79][88][89][90]

See also

References

  1. 1.0 1.1 1.2 Lua error in package.lua at line 80: module 'strict' not found.
  2. Lua error in package.lua at line 80: module 'strict' not found.
  3. 3.0 3.1 Lua error in package.lua at line 80: module 'strict' not found.
  4. 4.0 4.1 4.2 Lua error in package.lua at line 80: module 'strict' not found.
  5. 5.0 5.1 Lua error in package.lua at line 80: module 'strict' not found.
  6. Lua error in package.lua at line 80: module 'strict' not found.
  7. 7.0 7.1 Lua error in package.lua at line 80: module 'strict' not found.
  8. Lua error in package.lua at line 80: module 'strict' not found.
  9. 9.0 9.1 Lua error in package.lua at line 80: module 'strict' not found.
  10. 10.0 10.1 Lua error in package.lua at line 80: module 'strict' not found.
  11. 11.0 11.1 Lua error in package.lua at line 80: module 'strict' not found.
  12. 12.0 12.1 Lua error in package.lua at line 80: module 'strict' not found.
  13. Lua error in package.lua at line 80: module 'strict' not found.
  14. Lua error in package.lua at line 80: module 'strict' not found.
  15. Lua error in package.lua at line 80: module 'strict' not found.
  16. Lua error in package.lua at line 80: module 'strict' not found. [1] Superseded by: Lua error in package.lua at line 80: module 'strict' not found.
  17. Lua error in package.lua at line 80: module 'strict' not found.
  18. Lua error in package.lua at line 80: module 'strict' not found. (Yuval Yarom referring to the history.)
  19. Lua error in package.lua at line 80: module 'strict' not found. [2] (Fogh describing a Side Channel using fashioned listening to a safe while turning its wheel.)
  20. 20.0 20.1 Lua error in package.lua at line 80: module 'strict' not found.
  21. Lua error in package.lua at line 80: module 'strict' not found.
  22. Lua error in package.lua at line 80: module 'strict' not found.
  23. Lua error in package.lua at line 80: module 'strict' not found.
  24. Lua error in package.lua at line 80: module 'strict' not found.
  25. Lua error in package.lua at line 80: module 'strict' not found.
  26. Lua error in package.lua at line 80: module 'strict' not found.
  27. Lua error in package.lua at line 80: module 'strict' not found. Lua error in package.lua at line 80: module 'strict' not found.
  28. Lua error in package.lua at line 80: module 'strict' not found.
  29. Lua error in package.lua at line 80: module 'strict' not found.
  30. Lua error in package.lua at line 80: module 'strict' not found.
  31. 31.0 31.1 Lua error in package.lua at line 80: module 'strict' not found.
  32. Lua error in package.lua at line 80: module 'strict' not found.
  33. 33.0 33.1 Lua error in package.lua at line 80: module 'strict' not found.
  34. Lua error in package.lua at line 80: module 'strict' not found.
  35. Lua error in package.lua at line 80: module 'strict' not found.
  36. Lua error in package.lua at line 80: module 'strict' not found.
  37. 37.0 37.1 37.2 Lua error in package.lua at line 80: module 'strict' not found.
  38. 38.0 38.1 Lua error in package.lua at line 80: module 'strict' not found.
  39. Lua error in package.lua at line 80: module 'strict' not found.
  40. Lua error in package.lua at line 80: module 'strict' not found.
  41. Lua error in package.lua at line 80: module 'strict' not found. [3]
  42. 42.0 42.1 Lua error in package.lua at line 80: module 'strict' not found.
  43. Lua error in package.lua at line 80: module 'strict' not found.
  44. Lua error in package.lua at line 80: module 'strict' not found.
  45. Lua error in package.lua at line 80: module 'strict' not found.
  46. Lua error in package.lua at line 80: module 'strict' not found.
  47. Lua error in package.lua at line 80: module 'strict' not found.
  48. Lua error in package.lua at line 80: module 'strict' not found.
  49. "A Survey of Techniques for Dynamic Branch Prediction". Mittal, Sparsh; CPE, 2018
  50. Lua error in package.lua at line 80: module 'strict' not found.
  51. Lua error in package.lua at line 80: module 'strict' not found.
  52. Lua error in package.lua at line 80: module 'strict' not found.
  53. Lua error in package.lua at line 80: module 'strict' not found.
  54. Lua error in package.lua at line 80: module 'strict' not found.
  55. Lua error in package.lua at line 80: module 'strict' not found.
  56. Lua error in package.lua at line 80: module 'strict' not found.
  57. Lua error in package.lua at line 80: module 'strict' not found.
  58. Lua error in package.lua at line 80: module 'strict' not found.
  59. Lua error in package.lua at line 80: module 'strict' not found.
  60. Lua error in package.lua at line 80: module 'strict' not found.
  61. Lua error in package.lua at line 80: module 'strict' not found.
  62. Lua error in package.lua at line 80: module 'strict' not found.
  63. Lua error in package.lua at line 80: module 'strict' not found.
  64. Lua error in package.lua at line 80: module 'strict' not found.
  65. Lua error in package.lua at line 80: module 'strict' not found.
  66. Lua error in package.lua at line 80: module 'strict' not found.
  67. Lua error in package.lua at line 80: module 'strict' not found.
  68. Lua error in package.lua at line 80: module 'strict' not found.
  69. Lua error in package.lua at line 80: module 'strict' not found.
  70. 70.0 70.1 Lua error in package.lua at line 80: module 'strict' not found.
  71. 71.0 71.1 Lua error in package.lua at line 80: module 'strict' not found.
  72. 72.0 72.1 Lua error in package.lua at line 80: module 'strict' not found.
  73. 73.0 73.1 Lua error in package.lua at line 80: module 'strict' not found.
  74. 74.0 74.1 Lua error in package.lua at line 80: module 'strict' not found.
  75. Lua error in package.lua at line 80: module 'strict' not found.
  76. Lua error in package.lua at line 80: module 'strict' not found.
  77. Lua error in package.lua at line 80: module 'strict' not found.
  78. Lua error in package.lua at line 80: module 'strict' not found.
  79. 79.0 79.1 Lua error in package.lua at line 80: module 'strict' not found.
  80. Lua error in package.lua at line 80: module 'strict' not found.
  81. Lua error in package.lua at line 80: module 'strict' not found.
  82. Lua error in package.lua at line 80: module 'strict' not found.
  83. Lua error in package.lua at line 80: module 'strict' not found.
  84. Lua error in package.lua at line 80: module 'strict' not found.
  85. Lua error in package.lua at line 80: module 'strict' not found.
  86. Lua error in package.lua at line 80: module 'strict' not found.
  87. Lua error in package.lua at line 80: module 'strict' not found.
  88. 'WHAT THE F*CK IS GOING ON?' Linus Torvalds explodes at Intel spinning Spectre fix as a security feature, Patches slammed as 'complete and utter garbage' as Chipzilla U-turns on microcode, The Register, 2018-01-22.
  89. Molnar suggesting to use function tracing, Re: [RFC 09/10] x86/enter: Create macros to restrict/unrestrict Indirect Branch Speculation, Ingo Molnar, 2018-01-23.
  90. IBRS patch series, Intel, 2018-01-04.

Further reading

  • Lua error in package.lua at line 80: module 'strict' not found.
  • Lua error in package.lua at line 80: module 'strict' not found.
  • Lua error in package.lua at line 80: module 'strict' not found.

External links

Template:Speculative execution exploits