4 ms·

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 sys

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.

jo909 9y ago
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.
- static_noise 9y ago
  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.
  - jo909 9y ago
    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.
    - AstralStorm 9y ago
      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.)
JdeBP 9y ago
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.
mtgx 9y ago
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.

jo909 9y ago

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.

static_noise 9y ago
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.
- jo909 9y ago
  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.
  - AstralStorm 9y ago
    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.)

JdeBP 9y ago

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.

mtgx 9y ago

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.