Apple Confirms 'Meltdown' and 'Spectre' Vulnerabilities Impact Macs and iOS(macrumors.com)
macrumors.com
Apple Confirms 'Meltdown' and 'Spectre' Vulnerabilities Impact Macs and iOS
https://www.macrumors.com/2018/01/04/apple-meltdown-spectre-vulnerability-fixes/
1 comments
Could someone give me an ELI5 on Meltdown/Spectre..? I understand that they're vulnerabilities, but what is the risk and why is the worse bug in history?
They are both types of side-channel info leak attacks against CPUs.
——
The abstract from the Meltdown paper [1]:
The security of computer systems fundamentally relies on memory isolation, e.g., kernel address ranges are marked as non accessible and are protected from user access. In this paper, we present Meltdown. Meltdown exploits side effects of out of-order execution on modern processors to read arbitrary kernel-memory locations including personal data and passwords. Out-of-order execution is an indispensable performance feature and present in a wide range of modern processors. The attack is independent of the operating system, and it does not rely on any software vulnerabilities. Meltdown breaks all security assumptions given by address space isolation as well as paravirtualized environments and, thus, every security mechanism building upon this foundation. On affected systems, Meltdown enables an adversary to read memory of other processes or virtual machines in the cloud without any permissions or privileges, affecting millions of customers and virtually every user of a personal computer. We show that the KAISER defense mechanism for KASLR [8] has the important (but inadvertent) side effect of impeding Meltdown. We stress that KAISER must be deployed immediately to prevent large-scale exploitation of this severe information leakage.
——
The abstract from the Spectre paper [2]:
Modern processors use branch prediction and speculative execution to maximize performance. For example, if the destination of a branch depends on a memory value that is in the process of being read, CPUs will try guess the destination and attempt to execute ahead. When the memory value finally arrives, the CPU either discards or commits the speculative computation. Speculative logic is unfaithful in how it executes, can access to the victim’s memory and registers, and can perform operations with measurable side effects.
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, static analysis, containerization, just-in-time (JIT) compilation, and countermeasures to cache timing/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.
——
For more technical details, checkout Google's Project Zero blog [3].
[1]: https://meltdownattack.com/meltdown.pdf
[2]: https://spectreattack.com/spectre.pdf
[3]: https://googleprojectzero.blogspot.com/2018/01/reading-privi...
——
The abstract from the Meltdown paper [1]:
The security of computer systems fundamentally relies on memory isolation, e.g., kernel address ranges are marked as non accessible and are protected from user access. In this paper, we present Meltdown. Meltdown exploits side effects of out of-order execution on modern processors to read arbitrary kernel-memory locations including personal data and passwords. Out-of-order execution is an indispensable performance feature and present in a wide range of modern processors. The attack is independent of the operating system, and it does not rely on any software vulnerabilities. Meltdown breaks all security assumptions given by address space isolation as well as paravirtualized environments and, thus, every security mechanism building upon this foundation. On affected systems, Meltdown enables an adversary to read memory of other processes or virtual machines in the cloud without any permissions or privileges, affecting millions of customers and virtually every user of a personal computer. We show that the KAISER defense mechanism for KASLR [8] has the important (but inadvertent) side effect of impeding Meltdown. We stress that KAISER must be deployed immediately to prevent large-scale exploitation of this severe information leakage.
——
The abstract from the Spectre paper [2]:
Modern processors use branch prediction and speculative execution to maximize performance. For example, if the destination of a branch depends on a memory value that is in the process of being read, CPUs will try guess the destination and attempt to execute ahead. When the memory value finally arrives, the CPU either discards or commits the speculative computation. Speculative logic is unfaithful in how it executes, can access to the victim’s memory and registers, and can perform operations with measurable side effects.
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, static analysis, containerization, just-in-time (JIT) compilation, and countermeasures to cache timing/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.
——
For more technical details, checkout Google's Project Zero blog [3].
[1]: https://meltdownattack.com/meltdown.pdf
[2]: https://spectreattack.com/spectre.pdf
[3]: https://googleprojectzero.blogspot.com/2018/01/reading-privi...
They are both types of side-channel info leak attacks against CPUs.
You must know some hella smart five year olds. (Which is why I wish that meme would die already, because the correct answer to the question is, "no".)
But I'm not here just to make smart ass remarks, I think it ties into my experience reading the comments on a NYT story on the subject. 48 comments, and I think only one didn't demonstrate a severe lack of understanding.
<smug>That's why I don't use cloud stuff! Told ya so!</smug> Yeah, well, looks to me like you go to the wrong web page and you're pwnd.
<outrage>They just want to sell you new hardware!</outrage> Yup, twenty years all major chip makers have been sitting on this bug in the hopes they can sell you a new chip in 2018. Cyrix is getting the last laugh now!
And so on. But you've probably got about 300 chars to explain it before your average non-technical reader glazes over. And you don't get to use words like "side-channel". Good luck! Buffer overflows were easy to explain in comparison: "when ya try to put ten pounds of shit in a five pound bag, bad things happen. Developers aren't checking the size of their bag before they start shoveling." But this one? Hell, we've got Hacker News readers asking for a simplified explanation. And not to pick on you, jrullman, because that's a helpful summary, but that's the simplified explanation? And the reality is, yes, that's probably as simple an explanation as you're going to get.
You must know some hella smart five year olds. (Which is why I wish that meme would die already, because the correct answer to the question is, "no".)
But I'm not here just to make smart ass remarks, I think it ties into my experience reading the comments on a NYT story on the subject. 48 comments, and I think only one didn't demonstrate a severe lack of understanding.
<smug>That's why I don't use cloud stuff! Told ya so!</smug> Yeah, well, looks to me like you go to the wrong web page and you're pwnd.
<outrage>They just want to sell you new hardware!</outrage> Yup, twenty years all major chip makers have been sitting on this bug in the hopes they can sell you a new chip in 2018. Cyrix is getting the last laugh now!
And so on. But you've probably got about 300 chars to explain it before your average non-technical reader glazes over. And you don't get to use words like "side-channel". Good luck! Buffer overflows were easy to explain in comparison: "when ya try to put ten pounds of shit in a five pound bag, bad things happen. Developers aren't checking the size of their bag before they start shoveling." But this one? Hell, we've got Hacker News readers asking for a simplified explanation. And not to pick on you, jrullman, because that's a helpful summary, but that's the simplified explanation? And the reality is, yes, that's probably as simple an explanation as you're going to get.
Thanks! I appreciate it.