171

Canonical question regarding the 2018 Jan. disclosed Meltdown and Spectre Attacks. Other identical or significantly similar questions should be closed as a duplicate of this one.

Main concerns

  • What is speculative execution and what does it do?
  • What is the difference between Meltdown and Spectre?
    • How does Meltdown work?
    • How does Spectre work?
  • How do I protect myself?
  • Is the KPTI/KAISER patch sufficient to protect my computer?
  • The patch is claimed to induce a loss of performance; is it true? How much does this mean?
  • Can/should I disable the new patch if I'm worried about performance losses? What are the risks?
  • Which platforms and CPUs are vulnerable?
  • I'm running a virtual machine/containers; to what extent am I vulnerable?
  • Can I detect a Meltdown/Spectre attack on my computer?
  • Are these attacks remote code execution vulnerabilities?
  • Do I need to patch my software/website?
  • Can I be affected while visiting a website?
  • Can you explain this with an image?

References:

Tom K.
  • 7,913
  • 3
  • 30
  • 53
M'vy
  • 13,033
  • 3
  • 47
  • 69
  • Also, two (probably easily answered) questions: Are SPARC v7 and v8 CPUs (the 32-bit ones) safe, independent on the OS? (I think so, but I don’t know SPARC all that well.) Are Intel 80486- and P5-class CPUs (and in-order Atoms) safe from Spectre as well, or only from Meltdown? – mirabilos Jan 05 '18 at 17:34
  • @mirabilos I've read that SPARC systems are vulnerable to Spectre but not Meltdown and also that many are skeptical that Oracle will ever patch SPARC or Solaris since they no longer employ those teams(??). **All** processors that use speculative execution are vulnerable to Spectre, which includes Intel, SPARC, ARM and AMD, according to what I've read. Meltdown only affects Intel. – Todd Wilcox Jan 05 '18 at 18:00
  • Should this question be updated to ask about or clarify what has to be patched (potentially BIOS/firmware/microcode, hypervisors, guest OSes, **and** anti-virus, depending on the environment)? – Todd Wilcox Jan 05 '18 at 18:02
  • 2
    @ToddWilcox I knew about Meltdown, but I am still trying to gather enough information about Speculatius, eeh Spectre. The SPARC systems I’m talking about are 32-bit SPARC v7 and v8, produced by Sun/TI/Fujitsu/Ross/Cypress in the 1990s mostly, not the “UltraSPARC” v9 SPARC64 ones by Sun/Oracle and some others. There’s *absolutely* **no** information findable on the ’net which CPUs have speculative execution; [this article](https://www.raspberrypi.org/blog/why-raspberry-pi-isnt-vulnerable-to-spectre-or-meltdown/) was surprisingly helpful though, but I assume many older ones aren’t affected. – mirabilos Jan 05 '18 at 21:34
  • Related: https://raspberrypi.stackexchange.com/questions/77240/is-the-raspberry-pi-vulnerable-to-the-spectre-or-meltdown-exploit – Tom K. Jan 06 '18 at 12:30
  • @ToddWilcox It is inaccurate to say that **all** processors (current and future) which use speculative execution are vulnerable to Spectre. Speculative execution, itself, does not *inherently* make a processor vulnerable to Spectre. It's that there are secondary effects of the speculative execution which affect the state of the processor/system which are not fully reverted when the speculative execution is dependent on memory to which the current process is not supposed to have access. The malware must then be able to determine what has (likely) changed in the processor state. – Makyen Jan 08 '18 at 07:43
  • @Makyen “Accordong to what I’ve read”. I’m just relaying possibly inaccurate information. Seems to me the safest course is to assume a processor might be vulnerable until the manufacturer confirms one way or the other. – Todd Wilcox Jan 08 '18 at 12:44
  • Is there a (more or less) reliable test/PoC to tell if certain hardware is vulnerable? I found a few PoCs, but most of them are for Linux (currently I'm on Windows), the other are poorly documented. – David Balažic Jan 09 '18 at 13:05
  • 1
    Not only fun: https://xkcd.com/1938/ – F. Hauri - Give Up GitHub Jan 12 '18 at 11:30
  • 1
    @F.Hauri: And now it is clear how important basic security practices are: https://xkcd.com/1200. – user21820 Jan 14 '18 at 02:27
  • 1
    Note that grsecurity (commercial-only now) mitigates Meltdown with no performance hit without KPTI. – forest May 08 '18 at 03:09

3 Answers3

122

This answer is an attempt at addressing simply the main concerns. The details here might not be exemplary accurate, or complete. I'll try to link to more detailed explanations when possible.

What is speculative execution and what does it do?

Speculative execution is a feature of modern processors that comes as an optimisation. To allow for the parallel treatment of instructions into the processor pipeline, instructions can be processed ahead of time by using techniques such as branch prediction, value prediction or memory prefetch. Instructions can then be executed out-of-order.

This is a way to gain time by predicting correctly what happens next, instead of keeping the processor idle. When the prediction fails, the instructions are rolled back.

What is the difference between Meltdown and Spectre?

Meltdown exploits are globally easier to implement than Spectre.

Meltdown takes advantage of memory reads in out-of-order instructions, Spectre acts on the branch prediction mechanism.

Spectre allows for cross/intra process memory disclosure, Meltdown allows disclosure of kernel memory to the user-space processes (normally not accessible).

Meltdown has a known software mitigation.

Both rely on a cache side-channel attack, which is a measure of timing differences when accessing certain blocks of memory to deduce the information otherwise unknown.

How does Meltdown work?

In a nutshell, Meltdown works by asking the processor to load memory the user-space program should not have access to. Memory is read in an out-of-order fashion and put into cache. Using a side-channel attack (execution time measurement) on the cache, it is possible to infer the value of that memory location.

How does Spectre work?

Spectre works on a different level and does not allow access to kernel-space data from user-space. In this attack, the attacker tricks the speculative execution to predictively execute instructions erroneously. In a nutshell, the predictor is coerced to predict a specific branch result (if -> true), that results in asking for an out-of-bound memory access that the victim process would not normally have requested, resulting in incorrect speculative execution. Then by the side-channel, retrieves the value of this memory. In this way, memory belonging to the victim process is leaked to the malicious process.

How do I protect myself?

Update your operating system and/or hypervisor.

The main operating system distributors already release patches to implement the KPTI/KAISER behaviour. This is a means to reduce the attack surface by removing the user memory mapping of the kernel that are not strictly necessary for the processor to function.

Microcode (firmware) updates are likely to be release at some point.

Are the KPTI/KAISER patch sufficient to protect my computer?

No. And it only covers Meltdown.

The problem lies in the architecture design of the processors. To solve the problems completely (or even partially in the case of Spectre), at least a firmware update will be necessary. It is also possible that processors will have to be replaced by more recent models without this design flaw.

The patch is claimed to induce a loss of performance, is it true? How much does this mean?

Yes, but the loss incurred is dependent of the software workflow. Claims are it could range from 5% to 30% loss, depending on how system call reliant your software is. Benchmarks with high kernel-to-user space transitions, such as databases, have been reported to be the most affected.

This is still undergoing investigations, preliminary reports have been made (see links). However, since impacts vary by application, you should test the performance impact in your environment rather than relying on generic benchmarks.

Preliminary results (independent??):

Official announcements:

Can I/Should I disable the new patch if I worry about performance losses? What are the risks?

No. You can, but it's definitely not recommended.

First of all, if you're managing data from others, you would make your clients vulnerable to data theft.

Then, the performance losses still have to be properly evaluated and are highly dependent on your specific workflow. It's not a straight down 30% in performances.

Should you disable KPTI, you run the risk of having your confidential data leaked.

Which platforms and which CPU are vulnerable?

Most of the Intel CPU are vulnerable to both attacks. AMD CPU seems to be only affected by Spectre. Some ARM Cortex processors are affected, while all other ARM processors are not. PowerPC processors in the POWER 7, POWER 8, and POWER 9 families are affected, and others may be.

(see links for details).

I am running a Virtual Machine/Containers, to what extent am I vulnerable?

As per Steffen Ullrich's answer

  • Meltdown attacks do not cross VMs, only leaks kernel memory to local processes.
  • Spectre can work across VMs.

Also, from Steffen again, Meltdown and Spectre works with containers, as containers relies on the host kernel.

Can I detect Meltdown/Spectre attack on my computer?

It's very difficult, if even possible to.

Meltdown and Spectre both uses a designed property of the CPU that is triggered by innocuous programs all the time, making malicious programs difficult to tell apart from benign programs.

Are these attacks a remote code execution vulnerability?

No they aren't.

To be able to apply this attack, the attacker need to be able to execute code on the target host. Note however that if these are combined with other attack vectors, for example file upload or cross-site-scripting exploits, then there is a possibility of executing them remotely.

Do I need to patch my software/website?

In an ideal world, no.

In reality, some browser vendors already have implemented decrease in time accuracy measurements to mitigate the side-channel attacks. The KPTI should already provide a fair enough fix for programs using native system calls.

Can I be affected while visiting a website?

Yes, there's already a proof of concept of a Javascript exploit for Spectre (only).

Can you explain this with an image?

No, but Randall Munroe can:

XKCD #1938 - Meltdown and Spectre

[Source XKCD : https://xkcd.com/1938/]

Tom K.
  • 7,913
  • 3
  • 30
  • 53
M'vy
  • 13,033
  • 3
  • 47
  • 69
  • The answer to the question of performance impact is quite unfinished. Throwing out the numbers "5 to 30%" and vaguely mentioning system calls is not very helpful. The answer should explain what system calls are actually impacted (e.g. context switches) and therefore what workflows are affected (e.g. virtualization, heavy filesystem use) and not (e.g. gaming), and provide links to at least preliminary benchmark data such as found in several articles [here](https://www.phoronix.com/scan.php?page=home). – ArrowCase Jan 05 '18 at 15:43
  • 2
    @ArrowCase: *"...what system calls are actually impacted (e.g. context switches).."* - every system call makes a context switch. And the context switch is the part which got more expensive. Thus, the more system calls your application does per time the worse the additional overhead gets. Insofar *"..depending on how system call reliant your software is"* is correct. One might of course add some examples, like I/O heavy programs are more affected, computation intensive applications less etc – Steffen Ullrich Jan 05 '18 at 15:47
  • @ArrowCase I've been voluntarily vague about this because it's still on-going. I'll happily throw more details here when I know more. I've added the one you provided. – M'vy Jan 05 '18 at 15:56
  • @M'vy I made a pile of minor edits, and expanded some sentences based on my understanding. Feel free to roll back or amend my edits. I suggest adding a note about javascript to the "How does Spectre work?" section. – Mike Ounsworth Jan 05 '18 at 17:21
  • 1
    The resolution reduction patches for browsers etc. were obsolete before they were introduced: one team just spawned a second thread doing the equivalent of `volatile uint64_t i; while (true) ++i;` for counting. – mirabilos Jan 05 '18 at 17:32
  • 2
    Perhaps I'm missing something here, but in regards to Meltdown, you write that it "*works by asking the processor to load memory the user-space program should not have access to. Memory is read in an out-of-order fashion and put into cache...*" Why does executing a read out of order suddenly allow reads of kernel memory? – scohe001 Jan 05 '18 at 19:10
  • 27
    @scohe001: the explanation is simplified. The problem is that the CPU does not properly validate access restrictions for code that was executed speculatively out-of-order. Remember that *speculative execution* means that there is a significant chance that the results of executing the code are going to be thrown away, so it *seems* to make sense to delay costly access restriction checks. The result is that the memory access has already happened by the time the CPU throws away the speculatively executed code. The *second* problem is that the CPU does only clean up stuff that is directly … – Jörg W Mittag Jan 05 '18 at 20:29
  • 28
    observable, when it rolls back the speculatively executed code. What the researchers have found now, is a way to *indirectly* observe something that the engineers at Intel (and likely many other vendors as well) thought could not be observed. In particular, accessing data from cache is faster than accessing data from memory, and thus by measuring how long it takes to access particular data, the attacker can know which addresses are in cache and which aren't – Jörg W Mittag Jan 05 '18 at 20:31
  • 27
    The way the exploit works is that the speculative code encodes the data it read illegally into an address which it causes to be cached, and the exploit code can then find out via timing *which* address was cached. Let's just see how we can steal one bit of data: the speculative code reads one bit of data from the kernel and depending on what that bit is, it loads either address 0xdeadbeef or address 0xc00ffee. Now, everything gets rolled back as it should, *except* that whatever memory the "reader" code accessed is cached. Now, the exploit just needs to read those two addresses and see which … – Jörg W Mittag Jan 05 '18 at 20:34
  • 27
    comes back faster. So, the trick is that the speculatively executed code 1) reads some value from an address it shouldn't have access to, 2) encodes that value into an address it *does* have access to, 3) reads that address so that it is cached. The "normal" code then reads all the possible addresses (256 if we want to communicate 1 byte) and sees which one comes back faster than the others, then it knows what the byte at that address was. Repeat that over and over again, and you can eventually read the entire memory space. – Jörg W Mittag Jan 05 '18 at 20:37
  • @Childishforlife: You can't. It's read only. – Joshua Jan 05 '18 at 21:10
  • Can you link to this proof of concept JS only Spectre exploit? – David says Reinstate Monica Jan 05 '18 at 21:17
  • @DavidGrinberg: I think I remember seeing it on the webpage. The trick is to figure out a relation between JS coding patterns and the JITted code such that the JITted code contains instruction patterns that will lead to speculative memory accesses. Which means that the code is very specific to the version of the JIT compiler being used; the example exploit AFAIR works for V8 in Chrome. – Jörg W Mittag Jan 05 '18 at 22:21
  • 3
    If this is to be the canonical answer, then the 'How' is far too vague. For instance "Using a side-channel attack (execution time measurement) on the cache, it is possible to infer the value of that memory location"; what specific timing details are involved, and how exactly does knowing them allow memory values to be inferred? Same for Spectre's "Then by the side-channel, retrieves the value of this memory"; how is "I know the timing characteristics of a branch misprediction" a "side-channel"? What's the actual link between "I know how long things take" and "I can read any arbitrary data"? – aroth Jan 06 '18 at 00:10
  • 2
    @JörgWMittag: I'm still fuzzy on why it would makes sense to defer the validity check. A memory access can't start until the processor has fetched any required segment and page descriptors, and once the processor has those things checking whether a read is valid should take less time than fetching from even the fastest cache. So why allow the validity check to be deferred past the arrival of the fetched data? – supercat Jan 06 '18 at 00:54
  • 6
    @aroth this is to be the canonical 'Question'. If you feel you can give very detailed explanations about each attacks, I encourage you to add a new answer. My answer is an attempt to make the vulnerability clearer to the maximum of persons, including the non security-savvy. – M'vy Jan 06 '18 at 10:44
  • @aroth The difference in time tells you whether data was loaded into the cache or not. (Short time = data was loaded into cache, Longer time = it wasn't). I suggest to look into the Spectre paper for this, because an answer to a question like this would involve a lot of quoting. – Tom K. Jan 06 '18 at 12:54
  • 4
    @M'vy I don't have the necessary knowledge to do that. I was going to ask my own question about those details, then saw this one. I don't know much beyond what's in public reports, on Wikipedia, and in this answer here. With the exception of Jorg's comments, none of those sources make it remotely clear how being able to tell "whether data was loaded into the cache or not" (whether by timing or any other mechanism) can be extended (let alone, _reliably_ extended) to being able to freely tell what content resides in any arbitrary memory location of an attacker's choosing. – aroth Jan 06 '18 at 15:21
  • @DJMcMayhem the original Spectre paper already linked above. – user253751 Jan 07 '18 at 22:32
  • @supercat: "why allow the validity check to be deferred past the arrival of the fetched data?" That sounds like an excellent question of its own :-). Something like "What is the security tradeoff behind deferring the validity check in speculative execution". – sleske Jan 09 '18 at 10:24
  • @sleske: I think I found the answer to that. If L1 cache uses logical accesses, and the last access to logical 0x123456 yielded 0x78, then it makes sense for the next access to 0x123456 to speculatively assume that it is likely to yield 0x78 even if a page-table lookup and possibly actual memory fetch would be necessary to confirm that. If the actual memory fetch yields a page fault or if it yields different data, then any computations that used the value 0x78 would need to be redone. I would guess that there's an extra weakness, though, which is that... – supercat Jan 09 '18 at 15:49
  • ...the logic which populates the L1 cache may not validate whether the access was ever valid. So the first speculative access would end up getting discovered as invalid (since fetching the data would take as long as doing the page-table lookup) but arranging for the page-table entry to get bumped and repeating the access could use the L1-cached value. – supercat Jan 09 '18 at 15:51
  • You can check if your processors are susceptible to those vulnerabilities with `cat /proc/cpuinfo`. You should get a line like `bugs : cpu_meltdown spectre_v1 spectre_v2` which lists vulnerabilities. `lscpu` won't do it for you. – styrofoam fly Mar 16 '18 at 18:41
7

Simple tips

In addition to M'vy's excellent answer, I just want answer this question:

What can I do in order to be safe?

  • Spectre, Meltdown and Rowhammer are CPU conceptual bugs, so they couldn't be correctly patched by a software update. This means: Actual software patches do mostly decrase the overall performance of any system (Windows, Linux of MacOS).

  • These bugs also concern isolation. Knowing that:

    All isolation features (sandbox, containers, virtual host and users privileges) are now subject to caution!

    is the correct way of thinking!

  • Old security habits are now useful, such as:
    • having all sensitive applications located on physically dedicated hosts,
    • having one physical host for each sensitive customer (for providers),
    • storing importants data like backups and sensitive data like passwords or any secrets, on separated (dedicated) hosts.
    • browse network on dedicated host and do banking after a full desktop reboot or better: on another (dedicated) host!

If you do isolation by using different hardware hosts, you could safely use speculative execution and all other nice features (even with other, not already known, bugs) offered by modern CPUs. There is no need to decrase your system performances!

( If so, upgrading may not be the better way... ;-)

Why I think hardware separation/dedicated could be useful?

See this trip, published on April 17, 2013! (near than five years ago;)

Source: xkcd.com/1200

XKCD 1200

F. Hauri - Give Up GitHub
  • 4,597
  • 2
  • 19
  • 32
  • Could you maybe elaborate on your last statement? I'm not sure if this is true and I'm inclined to disagree/downvote. – Tom K. Jan 12 '18 at 13:27
  • 1
    @Tom If your installation is correctly isolated by hardware, then by upgrading softwares you just will decrase performances. So for this case, **and for this case only**, not aplying patches could let your system go fast... Of course, if you plan to use same desktop for web surf and banking, then your config don't fit this requirement! – F. Hauri - Give Up GitHub Jan 12 '18 at 14:40
  • @Tom ... And: As bug is hardware, changing the soft is the ***wrong*** answer. ( Plan to ask your provider to exchange your CPU while this must be *unger warranty"! ;-) – F. Hauri - Give Up GitHub Jan 12 '18 at 14:42
  • *"having one physical host for each sensible customs (for providers)"* - um, what? – Wildcard Jan 16 '18 at 01:44
  • @Wildcard Yes, simply... Or ask for CPU providers to exchange your CPUs! (See waranty conditions;) I'm sorry, but yes, this is a big challenge for hosting providers! – F. Hauri - Give Up GitHub Jan 16 '18 at 06:48
  • I am not questioning your conclusion. I just don't understand that sentence. "Each sensible customs" doesn't make sense as a phrase. No criticism implied as I know the language barrier can be difficult, but I don't even understand what you're trying to say well enough to suggest a rewording. – Wildcard Jan 16 '18 at 07:22
  • 4
    **I think** he means *sensitive* for «sensible» in all occurrences, and «customs» should be *customer*. – JDługosz Jan 16 '18 at 15:02
5

This answer is specific to the Spectre Next Generation attacks and will be updated as soon as new information are available.

Update, May 22nd:

The first patches are coming and so are more information regarding the new vulnerabilities:

Intel released this statement on May 21st 2018 which will give you a good overview over Spectre variants 3a and 4.
The respective CVEs are:

  • CVE-2018-3639 - Speculative Store Bypass (SSB) – also known as Variant 4
  • CVE-2018-3640 - Rogue System Register Read (RSRE) – also known as Variant 3a

Pretty much all Intel processors that were manufactured in the last 10 years are affected by these two vulnerabilities. Microcode updates have been made available to OS vendors, so they should be available to customers soon. Linux users should be safe if they updated their kernel recently and if their distribution uses retpolines.[citation needed]

If you want to know more about the technical details, Intel's whitepaper that analyzes speculative execution side channels - which was published after the Spectre and Meltdown attacks came to light - was extended to now cover variants 3a and 4. This is also true for this whitepaper which covers mitigation.

Further reading:
Jann Horn's original disclosure mail
AMD saying none of their products are vulnerable to SSB
ARM blog post
Debian security tracker
Intel blog Microsoft's analysis of SSB
Red HAT CVE DB
Red Hat vulnerability response
SUSE security blog
Ubuntu security notice
US CERT vulnerability note
VMWare Knowdlege Base article

Update, May 7th:

The planned publication of technical details has been delayed until at least May 21st and perhaps even longer because Intel was not able to finish development of the needed microcode updates.
But there was some new information published today, a list of the processors that are possibly affected by at least two of the eight new vulnerabilities:

  • all i-X processors and the respective Xeon derivatives since 2010 (these are also affected by the vulnerability described under '6')
  • Atom-based Pentium, Celeron and Atom processors since 2013

These first processor types are the typically used in desktop PCs, notebooks and servers. The second ones are used in tablets, smartphones und embedded devices.
There are no CVEs and no catchy names yet.

On May 3rd the German magazine c't - which is specialized in IT - reported that researchers have found eight additional vulnerabilities in Intel CPUs that all enable Spectre-like attacks. All these new vulnerabilities are based on the same design flaws as the vulnerabilities that are exploited by Spectre V1 and V2.

The first technical and in-depth report which will cover one of these vulns will probably be released on May 7th by the Google Project Zero. It is possible though, that other researchers or independent parties will release reports earlier.

What we know so far:

  1. There are eight new vulnerabilities.
  2. Each one will get its own CVE.
  3. Each one will require its own patch. There is little knowledge about the progress of the development of patches so far. According to the c't, Intel plans two patch waves: one in May and another in August.
  4. There is no list of affected processors yet. Intel processors are probably for the most part affected. Some ARM CPUs seem also to be affected. It is unclear so far if AMD CPUs are affected.
  5. Intel classifies four of the eight vulnerabilities as "high risk", the other four as "medium risk".
  6. One of the new vulns allegedly allows for very easy cross system attacks. An adversary might be able to attack a host system or other VMs from a source VM. This is especially dangerous for cloud providers. An attack like this was possible before, but it was very complex. The new vulnerability seems way easier to exploit. All other attack vectors seem very similar to Spectre V1 and V2.

Conclusion: We know very little so far and what we know are merely abstract descriptions of the new vulnerabilities. Spectre and Meltdown are very complex attacks and the underlying vulnerabilities are no less complex. All technical details will slowly flow into the discourse over the next few weeks. But the CPU vendors are informed and it seems that they and Kernel developers are already working on solutions. Have patience.

Source: https://www.heise.de/ct/artikel/Super-GAU-fuer-Intel-Weitere-Spectre-Luecken-im-Anflug-4039134.html

Tom K.
  • 7,913
  • 3
  • 30
  • 53