What are the key differences between recently discovered hardware vulnerabilities Meltdown and Spectre? I know that they both rely on speculative execution, but how does they differ from each other?
What are the differences between Meltdown and Spectre?
Asked Answered
What are the key differences between recently discovered hardware vulnerabilities Meltdown and Spectre?
Spectre
The Spectre attack has two flavors. The most dangerous flavor of Spectre uses branch misprediction and cache side effects to read any byte in current process virtual memory. It works on a variety of processors, including mobile phones, tables, etc.
So, why can't we just read any byte in current process, without any Spectre? Why Spectre is dangerous? There are variety of languages which create sandboxes (JavaScript) or virtual machines (Java) to isolate local machine from potentially dangerous code you downloaded from Internet.
Due to Spectre, there is no such isolation anymore, so JavaScript downloaded from a website can read any data within browser. Potentially, there might be some passwords, credit card numbers and other sensitive information.
Meltdown
Meltdown is a hardware issue on some processors (Intels, some ARMs, some IBM POWERs), which read memory and check privileges in parallel. This opens a possibility to read memory you have no privilege to access to. For example, user process is able to read kernel memory due to Meltdown.
Why Meltdown is dangerous? Kernel stores encryption keys, passwords or even physical pages of other processes, which due to Meltdown potentially could be read from any user process in the system.
Spectre vs Meltdown
The key difference between Spectre and Meltdown is that due to Spectre you can read or trick other processes to leak memory on the same privilege level, using Meltdown you can read memory you have no privileges to access.
Proof of concept
Here is my Linux Spectre-Based Meltdown (i.e. 2-in-1) proof of concept in just 99 lines of code:
https://github.com/berestovskyy/spectre-meltdown
It allows to read kernel space (i.e. Meltdown) using bounds check bypass (i.e. Spectre).
The key to meltdown is that a page-table entry has to exist but be mapped kernel-only. Meltdown can't read memory that isn't mapped at all. "memory you have no access to" is an over-simplification. It bypasses page-table permission checks, like x86's U/S bit (user/supervisor). –
Xeniaxeno
@PeterCordes thanks, I rephrased it to make it more correct. Regarding the mapping. Both attacks need mapping, i.e. you can't access unmapped page neither with Spectre nor Meltdown. The original question was about the differences. So yes, this is just a simple answer, not a full description of the attacks ;) –
Outdare
But with Spectre, you can access memory that the kernel has mapped (when in kernel mode), or another process running on the same physical core. Branch predictor aliasing means you don't even need to have memory mapped at the address of the branch you're attacking. I think that's a pretty fundamental difference. And yeah, I have a half-written answer to this question; it got pretty long and I didn't get back to finishing it, so I upvoted your shorter answer :) –
Xeniaxeno
@PeterCordes Thanks, Peter. Frankly, branch target injection variant of Spectre is very tricky and hard to implement, so I did not even mean this version answering the question. I've updated the answer to make it clear. –
Outdare
To get this started...
The papers on Meltdown (Moritz Lapp, et al) and Spectre (Paul Kocher et al) would be improved by proofreading... The latter in section 1.4 compares Spectre with Meltdown. This "melts" the barrier keeping the contents of the kernel inaccessible so that the runtime values may be read at a hundred KB a second, with low error. A forbidden memory access causes a "trap", but, before the trap is triggered, speculative advance execution of further code has changed a cache state (because an actual memory access was made by the ghost) which survives the cancellation of the other effects of the ghost execution. These changes can be detected.
Spectre however relies on misleading the branch-prediction in the microcode via presenting multiple innocuous usages to a IF ... THEN ... ; type statement, then specially-chosen data such that the test result will be false, but, the usual result having been true, the ghost execution will proceed to access some location of interest and modify a memory location on the basis of its value. Then the "false" result causes an undo of all the changes - except for the cache state. Alternatively, the Branch Target Buffer can be misled so that there will be a ghost execution of code that will access something of interest that should be inaccessible and again the results are suppressed but side effects remain.
It seems that over a hundred instructions can be in various stages of speculative execution, so relatively complex probing code is possible.
Meltdown
Meltdown breaks the most fundamental isolation between user applications and the operating system. This attack allows a program to access the memory, and thus also the secrets, of other programs and the operating system.
If your computer has a vulnerable processor and runs an unpatched operating system, it is not safe to work with sensitive information without the chance of leaking the information. This applies both to personal computers as well as cloud infrastructure. Luckily, there are software patches against Meltdown.
Spectre
Spectre breaks the isolation between different applications. It allows an attacker to trick error-free programs, which follow best practices, into leaking their secrets. In fact, the safety checks of said best practices actually increase the attack surface and may make applications more susceptible to Spectre
Spectre is harder to exploit than Meltdown, but it is also harder to mitigate. However, it is possible to prevent specific known exploits based on Spectre through software patches.
Source:
To get a better understanding you also want to watch this fine video on Spectre & Meltdown by Computerphile:
© 2022 - 2024 — McMap. All rights reserved.