Hacker News Reader

Comment by twoodfin | Hacker News Reader

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.

View on HN

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.

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.

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.

`/dev/mem` is not available in a container, so I cannot use `/dev/mem` to read other tenants' memory on my VPS.

Reply on news.ycombinator.com