Timeline of Events: Meltdown & Spectre
-1995: The first vulnerable processors begin production. Coincidentally, Jann Horn was born around this time--the problem has been hidden for so long that it and the person who discovered it were born at the same time.
-1995-2017: Vulnerabilities exist, but aren’t uncovered and addressed (hindsight will probably reveal warning signs, though).
-April 2017: Jann Horn, a member of Google’s Project Zero security analysis team, stumbles on speculative execution vulnerabilities and begins digging.
-May 2017: Horn develops proof-of-concept Spectre attack.
-June 1 2017: Horn notifies Intel, AMD and ARM of the Spectre exploit.
-Late June 2017: Horn notifies Intel of Meltdown exploit.
-July 28 2017: Anders Fogh of G Data publishes a blog entry describing theoretical abuse of speculative execution. He doesn’t develop a working exploit, but still draws some interest. According to Fogh the roots of this post stretch back as far as late 2016, but he notes that Horn didn’t have access to this and did his research/reporting independently and before the public blog post.
-September 2017: Mike Hamburg alerts Paul Kocher of Cryptography Research to possible problems with speculative execution; Kocher eventually develops his own working Spectre proof-of-concept and notifies manufacturers. Both men are listed as authors of the Spectre and Meltdown papers.
-October-November 2017: Multiple major manufacturers begin to express unusual interest in the Graz University team’s KAISER patch (Kernel Address Isolation to have Side-channels Efficiently Removed), raising suspicions and leading them to more closely examine Fogh’s work and discover Meltdown.
-November 2017: Cyberus team examines Fogh’s work and discovers Meltdown.
-December 2017: Graz and Cyberus teams both privately notify Intel; rumors begin to circulate publicly. At this point, Spectre has been reported to manufacturers by Google (Horn) and Kocher, and Meltdown has been reported to Intel by Google, Graz, and Cyberus. All of these reports were made independently.
-January 3 2018: The cat officially exits the bag as Google publicly discloses exploits six days ahead of schedule* due to increasing publicity and rumors. Project Zero’s detailed explanation is posted later the same day. Manufacturers (i.e. Intel) scramble to issue patches.
-January 4 2018: Google reveals Spectre mitigation technique “retpoline,” which they have used internally with “negligible impact on performance.”
-January 5 2018: Former and current members of the United States National Security Agency state that the NSA was unaware of the vulnerabilities in an article from The Washington Post.
-January 10 2018: Intel publishes concerning benchmark numbers for their initial patch and approximately one billion people email and tweet at us about it.
-January 11 2018: Intel briefly acknowledges a problem with their patch causing reboots on Broadwell and Haswell.
-January 17 2018: In a more detailed post, Intel reveals that the patch reboot issue not only affects Haswell and Broadwell, but also “Ivy Bridge-, Sandy Bridge-, Skylake-, and Kaby Lake-based platforms.”
-January 21 2018: Linux creator Linus Torvalds (a.k.a. “no, not that Linus”) describes Intel’s patches as “COMPLETE AND UTTER GARBAGE.”
* Note that there’s a period of more than 200 days between Horn notifying manufacturers of Spectre and Project Zero’s planned disclosure date. Project Zero was created in 2014 with the intent to privately notify manufacturers of issues and then announce them “typically once a patch is available.” They have their limits, though: later that year, they notified Microsoft of a Windows 8.1 bug and went public after it went unpatched for 90 days. Allowing manufacturers a 200+ day grace period to develop a patch for a vulnerability that’s existed for two decades indicates just how serious this is. The grace period was only cut short by six days, and still everything went to hell in a handbasket as soon as the news broke.
Meltdown & Spectre Interview, Part 1
The widespread “we’re all going to die” sensationalism of the first few days wasn’t helpful, but the inevitable “this isn’t a problem and everyone is overreacting” backlash is equally misguided; for example, we’ve seen some commenters and publications claiming that Meltdown and Spectre require physical access. We reached out to several researchers from the timeline above in order to clear-up these misconceptions.
We received responses from G Data, Cyberus Technology, and a Graz University team member. Of those replying, we spoke with Anders Fogh (G Data), one of the first to draw public attention to potential abuse of speculative execution (see interviews with his own employer and NYMag for more), Werner Haas and Thomas Prescher (Cyberus), one of the teams to independently discover Meltdown and authored the Spectre/Meltdown papers, responses relayed together by Mr. Haas), and Michael Schwarz of the Graz University team, responsible for Meltdownattack.com.
--
GamersNexus: We have read some media reports online that suggest Spectre requires physical access to the device in order to be used as an attack. (A) Is this true? (B) Could a Spectre attack be executed remotely or via browser/hijacked ad networks, theoretically speaking?
Anders Fogh (Gdata):
- “Neither Spectre or Meltdown require physical access. They are purely software, that just utilize how hardware works.”
- “Both Spectre and Meltdown have been shown to work in javascript and thus hijacked or purchased ads that support javascript as well as malicious websites can be used as a vector for both. Browser vendors are aware of it and has proposed and implemented some mitigations also KPTI will do well against Meltdown from a browser. I strongly recommend using KPTI and an updated browser when surfing the internet. Further current versions of Spectre and Meltdown are members of the class of timing attacks. Other timing attacks has been shown to be launchable over the network even without javascript. Thus, it is theoretically possible that we’ll see such attacks in the future. My personal opinion is that this is more likely to be an academic exercise than a real world vector.”
Werner Haas & Thomas Prescher (Cyberus Technology): “The short answers are ‘no’ and ‘maybe.’”
- “For the long story, here is the background on the attacks: Meltdown and Spectre both require code execution on the victim machine. How this code is getting deployed is irrelevant, though. Physical access in my definition implies an attacker can touch the device and can manipulate e.g. I/O devices.
- “In case of questionable web content, there is the risk of executing unvetted JavaScript code. The good news is that Browser Vendors have already rolled out patches addressing the vulnerabilities. An attacker needs good quality timing information in order to be able to detect the traces of (misled) speculative execution in the caches.”
Michael Schwarz (Graz University Team): Spectre can be mounted from JavaScript (thus, in the browser), as described in the Spectre paper.
GamersNexus: Of the media reports and online comments you've read, what are some common misconceptions you've encountered? Are there any misunderstandings of your research that you would like to address?
Anders Fogh: “I think it’s not always well reflected that speculative execution is a leverage to side channels.* With that I mean speculative execution without side channels is innocuous, but side channels without speculative execution are dangerous though less so than with. In fact, Spectre-style attacks can be launched without speculative execution, but would usually require the presence of a classic software bug. Even in the absence of software bugs and speculative execution we can do scary things with side channels.”
Werner Haas & Thomas Prescher: “First, there is nothing wrong with speculative execution or using caches. Both are a basic prerequisite to get any kind of performance. Second, requests for the replacement of all processors currently in use are unduly exaggerated. Having a vulnerable CPU does not imply that the system can be readily compromised.
“Meltdown is a really annoying flaw but it is fairly obvious what needs to be changed in hardware so I fully expect upcoming processors not to be susceptible. In the mean time, patches like Linux KPTI provide effective protection. With Spectre I would argue that all current hardware modifications are mere stop-gap solutions. I guess it will take some time and good old fashioned research to figure out the most efficient way of mitigating such attacks.”
Michael Schwarz: “Many people see it as ‘just another bug,’ which can be fixed as every bug. The common misunderstanding here is that this problem is in hardware, which cannot simply be updated.
“Another misunderstanding is that Meltdown/Spectre is not an issue, because you need code execution, and ‘nobody has code execution on a computer which is not a cloud system.’ People often do not realize that they run untrusted code all the time, e.g. JavaScript in the browser or apps from the app store. This code is normally run in a sandboxed environment, and can therefore not harm the system. However, with Meltdown/Spectre, the sandboxing can be circumvented, and the untrusted code has access to the whole system.”
GN: Do you feel there are any points of Meltdown/Spectre that are being overlooked, or not being given enough attention?
AF:
- “Of the two, Meltdown surely is the more dangerous one fortunately it is also the easier problem to fix. Spectre in my opinion will in variations be with us for a very long time, but it’ll probably lose importance with time as we figure out better and better approximations for a solution.
- We really need to have a discussion about ad networks’s use javascript”
WH & TP: “I guess on the Meltdown side, I am disappointed that we still know very little about the low level details. For example, initially I postulated that presence in L1 would be required but now I am fairly confident that any memory location can be read. The memory subsystem is rather opaque and it would be nice to have some insight. This is probably irrelevant from a security perspective but it could help writing more efficient code.
“With respect to Spectre it became obvious that CPU software (aka microcode) is not being developed with the same level of quality as the hardware (at least at Intel). What I find irritating is that enabling 3 new MSR capabilities related to branch prediction can trigger reboots (OK, I am oversimplifying a bit). The public is left wondering about what is really going on which certainly does not increase my confidence in a solution.”
---------------------------
* From an ENISA brief: “Side-channel attacks exploit observable and measurable computational side effects to extract/infer otherwise unavailable secret information/data. Side-channel attacks are well known to be used against cryptographic operations.”
Meltdown & Spectre Interview, Part 2
Those responses raised some more questions, so we followed up with Mr. Fogh.
GN: To what extent is AMD affected in all of this? We always hear about Intel with Meltdown -- do AMD users need to be concerned? We understand that Spectre impacts just about everything, but our understanding is that Meltdown doesn't affect their [AMD’s] CPUs. Do you have any thoughts on this?
AF: “AMD appears not to be affected by Meltdown, which is the more severe issue of the two. AMD, however, are affected by Spectre. How bad they are affected depends on specifics in the pipeline details. I don't have an AMD to run test on so you'll have to suffice with an educated guess. I don't think there'll be much difference in severity between AMD and Intel in terms of Spectre. While it certainly is not as bad as Meltdown, we are still talking about an issue that can lead to complete disclosure on higher privileged memory and that should not be taken lightly.”
GN: What are your thoughts on the patches/fixes that have been issued thus far?
AF: “First, I think defenders have reacted remarkably well. The issues are really complex. KPTI for instance is probably the most substantial change in how modern operating systems work in the past decade. From OS vendors being faced with meltdown to KPTI was shipped was only half a year. That is impressive by any standard. In my opinion, the Spectre fixes that we are seeing is first generation fixes and there is still work to be done with those. I think there is room for improvement both for software fixes (I'm actively researching this) and hardware fixes both in terms of security benefit and performance costs. As for intel's patches, they certainly are not good solutions, but it's probably all they can do. The background here is that testing, debugging and developing CPUs is really difficult because emulators have severe limitations and producing real CPU is expensive and time consuming. Hence modern CPU has functionality that assists future development efforts but isn't exposed for use in end product. The microcode updates we are seeing from Intel is in my opinion likely to be features meant for development being exposed to operating system vendors and used for something they were never meant to do. Better approaches requires new CPUs and from figuring out the change you wish to make until you can actually ship a new CPU is a process that takes years. A real solution is even further away, we quite simply don't know how to build CPUs without side channels and a one-to-one replacement for speculative execution is not known either. So my guess is we'll see incremental improvements as time progress.
“There certainly is a trade off between performance and security and people will always complain about how the trade off is made. For normal users it's unlikely that performance will be a big issue. But for special applications and in enterprise/server world performance issues certainly can be a thing. That said many of the early performance penalties that where discussed are either out of context, wrong or more due to bad programming than CPU design. For server/enterprise equipment it remains an option to run unpatched systems and protect them otherwise - say using airgaps, code whitelisting policies, network barriers etc. Nevertheless people such as gamers and tuners are much worse off - the need the security because they need the patches from a security perspective and are hell bent on performance on the other hand.”
GN: Do you have any recommended steps that PC users should take to safeguard themselves against these exploits? Should they also take steps to safeguard networking devices (routers, switches, NAS, etc?)
AF: “Updating browsers and operation is the most important thing for the normal users. It's alway a good idea to update networking devices regularly and Spectre/Meltdown is a good opportunity to do so. Generally I'd be less worried about these kind of devices from a Spectre/Meltdown perspective at least short term.”
Conclusion: Meltdown & Spectre One Month Later
Again, speculative execution isn’t the bogeyman: it’s just one feature of modern processors that can be twisted towards dishonest purposes. There’s no specific evidence that these exploits have been used yet outside of proof-of-concept attacks, but the possibility is very real and needs to be addressed, hence the mad scramble to develop patches. Manufacturers have a lot more to worry about at this point than consumers do, and there must be hardware-level changes going forward to truly solve the issue--everyone’s going to have to deal with Spectre in particular, and that includes Intel, AMD, ARM, Apple -- everyone. Software patches are an effective stopgap measure until then.
For the gamers and overclockers, extra security at the cost of performance is unfortunate, but it’s necessary. We mentioned earlier the 200-ish day grace period between Intel being alerted to a Meltdown and the public announcement, but as Fogh points out, that’s a small window to develop changes at this scale. The reboot bugs with Intel’s patch are embarrassing and the industry as a whole is tripping over its shoelaces, but once the kinks are ironed-out, computers in general will be more secure (or at least as secure as they should have been in the first place).
The answer to “where are we now?” is “somewhere between a problem being revealed and a truly stable solution being developed,” but progress is being made. Reassure your grandparents that Meltdown and Spectre are exploits that were reported by researchers and security analysts, not viruses that hackers are using to melt their computer. For consumers, the best course of action is to dutifully apply browser/OS updates and check the news carefully when a new processor generation is released to see whether appropriate changes have been made.
Editorial: Patrick Lathan
Host, Video Writer: Steve Burke
Video: Andrew Coleman
