I'd say Heartbleed was worse. This one requires local code execution, whereas Heartbleed was "connect to any OpenSSL-using server, send a magic packet, and read the private keys from its memory."
True, though the fix for Meltdown requiring a performance hit might exacerbate bad incentives (people not wanting to upgrade) or bad publicity for major corporations (server hosts whose clients now have degraded performance). Whereas Heartbleed had a security cost, this has a possible financial cost.
Also the unpatched devices. Millions of phones don't receive patches anymore, whereas most servers do get patches. They're not really comparable in scale.
The difference is scale. OpenSSL was on a lot of servers, but this affects literally every device manufactured in the last 9 years or so. A well-crafted virus could infect nearly any computer and exploit it reliably. We're talking billions and billions of devices, as opposed to millions by Heartbleed.
From my understanding, the VM can exploit it too via executing a crazy amount of syscalls. I may be misunderstanding, but if that were not the case I doubt that AWS would be forcing quick reboots of a ton of its VMs.
Edit: Wait, sorry, I misread. Read is all you really need, write would just be a cherry. If you can read the memory of the host kernel, then you can gain access to any other VMs on the system. This one is bottom-up, you need access to one system and in theory you can gain access to thousands.
… and nowadays almost everyone permits remote sites to execute code in their browsers. I don't know if JavaScript can be used to implement Meltdown though.
This research has implications for products and services that execute externally supplied code, including Chrome and other browsers with support for JavaScript and WebAssembly.
> Currently, we have only verified Meltdown on Intel processors. At the moment, it is unclear whether ARM and AMD processors are also affected by Meltdown.
> In particular, we have verified Spectre on Intel, AMD, and ARM processors.
Interesting. So there are two different vulnerabilities. Spectre has been verified to affect Intel and AMD whereas Meltdown may affect both.
Edit: based on this statement,[1] AMD states they are not affected at all. This seems to be contrary to what the researchers have found?
>The Project Zero researchers discovered three methods (variants) of attack, which are effective under different conditions. All three attack variants can allow a process with normal user privileges to perform unauthorized reads of memory data, which may contain sensitive information such as passwords, cryptographic key material, etc.
> There is no single fix for all three attack variants; each requires protection independently. Many vendors have patches available for one or more of these attacks.
That would suggest the possibility of a third unnamed attack variant.
The core of this attack is extremely simple and elegant; use a value from a speculated-but-not-completed instruction as an index, causing one of a set of cachelines to be touched; then use a timing measurement on those cachelines to see which one was accessed, thus determining the value.
This is a nightmare for the cloud, but IMHO for personal computing, it only furthers the notion that you should trust every bit of code running on your system, and my long-standing view that protection features like paging, rings, and access bits should really be considered more of barriers to prevent accidents than any real isolation. Timing-based sidechannels are notoriously difficult to excise completely.
"While the updates AWS performs protect underlying infrastructure, in order to be fully protected against these issues, customers must also patch their instance operating systems."
Prior to this quote, Amazon said that virtually all of the underlying instances have been patched.
What's the risk between now and when all of my EC2 instances are restarted with updated AMIs? Is it the 'full' risk, or is the attack less feasible, given the patched underlying OS'. Thanks.
TLDR: two side-channel info leak attacks on CPUs: Meltdown that appears to affect Intel and latest ARM64 (Cortex-A75), and Spectre that was shown to affect Intel, older AMD and ARM64 and theoretically newer AMD processors.
Meltdown is more severe with read privilege escalation (javascript in browser could read kernel memory!), which has a kernel patch (KPTI) that can slow down many workloads by 30%.
Spectre also allows a user process to read memory of other processes/containers and potentially kernel, which was shown to work on Intel and ARM64 because their predictable branch prediction impl (Tomasulo). Newer AMD (Ryzen and Epyc) employs a hardware neural network for branch prediction, which is much less predictable but still theoretically possible to exploit. This is probably not the first time that the opacity of a neural network helped security :)
26 comments
[ 2.8 ms ] story [ 68.2 ms ] threadHowever, from what I'm understanding, this makes Heartbleed look like a papercut.
Edit: Wait, sorry, I misread. Read is all you really need, write would just be a cherry. If you can read the memory of the host kernel, then you can gain access to any other VMs on the system. This one is bottom-up, you need access to one system and in theory you can gain access to thousands.
… and nowadays almost everyone permits remote sites to execute code in their browsers. I don't know if JavaScript can be used to implement Meltdown though.
This research has implications for products and services that execute externally supplied code, including Chrome and other browsers with support for JavaScript and WebAssembly.
> In particular, we have verified Spectre on Intel, AMD, and ARM processors.
Interesting. So there are two different vulnerabilities. Spectre has been verified to affect Intel and AMD whereas Meltdown may affect both.
Edit: based on this statement,[1] AMD states they are not affected at all. This seems to be contrary to what the researchers have found?
1 - https://twitter.com/rhhackett/status/948676213505232897
When AMD says they are "not susceptible to all three variants", that's a NAND, not a NOR.
>The Project Zero researchers discovered three methods (variants) of attack, which are effective under different conditions. All three attack variants can allow a process with normal user privileges to perform unauthorized reads of memory data, which may contain sensitive information such as passwords, cryptographic key material, etc.
> There is no single fix for all three attack variants; each requires protection independently. Many vendors have patches available for one or more of these attacks.
That would suggest the possibility of a third unnamed attack variant.
[0] https://security.googleblog.com/2018/01/todays-cpu-vulnerabi...
https://freedom-to-tinker.com/2005/09/09/acoustic-snooping-t...
Has anyone applied similar methods to pen on paper?
This is a nightmare for the cloud, but IMHO for personal computing, it only furthers the notion that you should trust every bit of code running on your system, and my long-standing view that protection features like paging, rings, and access bits should really be considered more of barriers to prevent accidents than any real isolation. Timing-based sidechannels are notoriously difficult to excise completely.
From https://aws.amazon.com/de/security/security-bulletins/AWS-20...:
"While the updates AWS performs protect underlying infrastructure, in order to be fully protected against these issues, customers must also patch their instance operating systems."
Prior to this quote, Amazon said that virtually all of the underlying instances have been patched.
What's the risk between now and when all of my EC2 instances are restarted with updated AMIs? Is it the 'full' risk, or is the attack less feasible, given the patched underlying OS'. Thanks.
Meltdown is more severe with read privilege escalation (javascript in browser could read kernel memory!), which has a kernel patch (KPTI) that can slow down many workloads by 30%.
Spectre also allows a user process to read memory of other processes/containers and potentially kernel, which was shown to work on Intel and ARM64 because their predictable branch prediction impl (Tomasulo). Newer AMD (Ryzen and Epyc) employs a hardware neural network for branch prediction, which is much less predictable but still theoretically possible to exploit. This is probably not the first time that the opacity of a neural network helped security :)