
Xen Project Spectre/Meltdown FAQ - r4um
https://blog.xenproject.org/2018/01/04/xen-project-spectremeltdown-faq/
======
weinzierl
> 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?

~~~
riffraff
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
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
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
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
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.)

------
lowbloodsugar
>There are two angles to consider for this question:

>Can an untrusted guest attack the hypervisor using Meltdown or Spectre?

>Can a guest user-space program attack a guest kernel using Meltdown or
Spectre?

There are two angles if you maintain Xen yourself. However the vast majority
of people aren't Xen customers, they are customers of Amazon or other cloud
provider. In which case the main concern is:

 _Can a fellow customer guest running on an AWS instance attack my guest
account?_

It seems like the answer is "No", but it looks like the answer might be "Only
if dom0 is patched", and might even be "Yes". Since it's not in AWS interests
to publicize that the answer is Yes, and since AWS is a large user of Xen, I
find the it unsettling that this question is unanswered. It makes me thing it
is unanswered for a reason. And if the response is "Oh, we didn't think about
it from that perspective", then that would be even more disturbing.

------
fyi1183
The linked advisory 254 claims that SP2 is limited to code after bounds checks
and similar when SMEP is used.

This is incorrect: the BTB can be poisoned to speculatively jump anywhere in
the text segment of the supervisor.

------
nukeop
Intel PR monkeys are trying to take AMD down with them, let's make this clear:

For the 3 bugs, the biggest one only affect Intel CPUs, for bug 2 and 3:

AMD bug only affects THE SAME PROCESS, unlike Intel, which allows exploits to
cross processes:

[https://googleprojectzero.blogspot.com/2018/01/reading-
privi...](https://googleprojectzero.blogspot.com/2018/01/reading-privileged-
memory-with-side.html)

"As shown, AMD was only vulnerable to "the ability to read data inside mis-
speculated execution within the same process, without crossing any privilege
boundaries."

~~~
static_noise
Which would be a more appropriate term for the word "monkey" in this context?
With monkey I associate being uncoordinated and stupid. I am very sure that
this is not the case.

~~~
ForHackernews
"PR flacks" has a long and (dis?)honourable history
[http://www.edsonpr.com/NEWS/Cheklist_summer06.pdf](http://www.edsonpr.com/NEWS/Cheklist_summer06.pdf)

~~~
ajobaccount2017
You meant "PR flaks"?

~~~
ForHackernews
That's up for debate!

[http://grammarist.com/spelling/flack-
flak/](http://grammarist.com/spelling/flack-flak/)

[http://www.prnewsonline.com/prnewsblog/flackflak-which-do-
yo...](http://www.prnewsonline.com/prnewsblog/flackflak-which-do-you-prefer/)

