3 ms·

Reading secret data out of kernel memory is very bad on cloud environments. Keep in mind that the kernel deals with a lot of cryptography.

twoodfin 9y ago
Is there anything this bug can give you that you can't get with sudo cat /dev/mem ? I'm having a hard time understanding why this is worse than any other local root escalation bug except for the consequences of the necessary patch. EDIT: I see that /dev/mem is no longer a window on all of physical RAM in a default secure configuration. Is it true that there's no way for root to read kernel memory in a typical Linux instance? If so, the severity of this issue makes more sense to me.
- pcwalton 9y ago
  You don't need to be root. > I'm having a hard time understanding why this is worse than any other local root escalation bug except for the consequences of the necessary patch. It's not, as far as I'm aware. The fact that the patch has perf consequences is why it's such a big deal.
- dboreham 9y ago
  I think the idea is that it is worse because the bug is in the hardware. The OS patches are just a workaround to make the hardware bug unexploitable, and they can lead to a significant performance penalty.
- rav 9y ago
  `/dev/mem` is not available in a container, so I cannot use `/dev/mem` to read other tenants' memory on my VPS.
- ProblemFactory 9y ago
  We don't know what the actual bug is yet, or how easy it would be to exploit it. People are speculating that either: a) It would allow any non-root process to read full memory, including the kernel and other processes, or b) It would allow one cloud VM to read full memory of other cloud VMs on the same physical machine, or c) With enough cleverness, it would allow even sandboxed Javascript on a web page to read full memory of the computer that it is running on.
justinclift 9y ago
Sounds like reading HTTPS cert/key details from other-peoples-VM's on cloud providers wouldn't be too much of a stretch. Especially with the memory dumping demo. Combine that with something that looks for the HTTPS private key flag string and it's sounding pretty feasible. :/

twoodfin 9y ago

Is there anything this bug can give you that you can't get with sudo cat /dev/mem ? I'm having a hard time understanding why this is worse than any other local root escalation bug except for the consequences of the necessary patch. EDIT: I see that /dev/mem is no longer a window on all of physical RAM in a default secure configuration. Is it true that there's no way for root to read kernel memory in a typical Linux instance? If so, the severity of this issue makes more sense to me.

pcwalton 9y ago
You don't need to be root. > I'm having a hard time understanding why this is worse than any other local root escalation bug except for the consequences of the necessary patch. It's not, as far as I'm aware. The fact that the patch has perf consequences is why it's such a big deal.
dboreham 9y ago
I think the idea is that it is worse because the bug is in the hardware. The OS patches are just a workaround to make the hardware bug unexploitable, and they can lead to a significant performance penalty.
rav 9y ago
`/dev/mem` is not available in a container, so I cannot use `/dev/mem` to read other tenants' memory on my VPS.
ProblemFactory 9y ago
We don't know what the actual bug is yet, or how easy it would be to exploit it. People are speculating that either: a) It would allow any non-root process to read full memory, including the kernel and other processes, or b) It would allow one cloud VM to read full memory of other cloud VMs on the same physical machine, or c) With enough cleverness, it would allow even sandboxed Javascript on a web page to read full memory of the computer that it is running on.

justinclift 9y ago

Sounds like reading HTTPS cert/key details from other-peoples-VM's on cloud providers wouldn't be too much of a stretch. Especially with the memory dumping demo. Combine that with something that looks for the HTTPS private key flag string and it's sounding pretty feasible. :/