Hacker News Reader

Comment by weinzierl | Hacker News Reader

> Is there any risk of privilege escalation?

> Meltdown and Spectre are, by themselves, only information leaks. There is no suggestion that speculative execution can be used to modify memory or cause a system to do anything it might not have done already.

Aren't they a bit too casual here? The answer is not wrong in the sense that Meltdown and Spectre themselves can't directly be used for privilege escalation.

On the other hand the question they posed was: "Is there any risk of privilege escalation?" and I wouldn't be so quick about that. If I can read arbitrary kernel memory isn't there a chance (at least under some circumstances) that I can find something (clear text or hashed root password maybe) that enables trivial privilege escalation?

View on HN

Their reply still looks correct, there is no way you could find a key of some kind that allows you to escape from a xen VM, or as they say "do something the system might not have done". At least in my understanding.

Their sentence as such is correct, but only half the truth. You can not change the behavior of the system using this specific attack. It is only an information leak.

BUT you might be able use the privileged information you might gain to launch another "active" attack using another method. This will have to be specific to what data you found and if there is an attack surface for it.

Is it typical for VM hosts to allow some kind of remote administration which - at some near or distant point - is shared with the communication channels of the VM guests?

E.g. a ssh connection over the internet where the attacker gains access to the keys necessary to connect as a user or join an active session.

No, that would be bad design any day of the year. You would limit the attack surface of the hypervisor as much as possible, which means near to zero network access from the internet or customer networks.

But that is just not enough. As their advisory states this might allow reading memory of other guests, and who knows what that guest is doing and what next attack that might lead to. Anything you can imagine, really. The attacker might find keys that allow access to systems not even running on that platform. Maybe user passwords. Maybe private mails or documents. Any data the other guest ever processes is at risk.

It's not a guaranteed win and very limited possibilities to automate. But the potential harm could be unbelievable.

This vulnerability (cross-guest and cross-process) does not exist in AMD CPUs. You can still exploit this in-process to say gather information to bypass ASLR for example. (Not too easy and very CPU specific, as the perceptron-like predictor is not as predictable in behaviour and has been retuned many times.)

That depends from how narrowly one conceives privilege escalation. The ability to read something that you have not been granted read privileges for is a privilege escalation, too. The access that one gains with escalated privileges is not solely confined to write access; there is read access to be gained too.

Eh, it still sounds a bit hand-waivy. I'll wait for a post from Joanna Rutkowska on this, as these bugs may directly affect Qubes, and Xen has kept her on the dark about the bugs/patches so far.

Reply on news.ycombinator.com