Xen Project Spectre/Meltdown FAQ(blog.xenproject.org)
blog.xenproject.org
Xen Project Spectre/Meltdown FAQ
https://blog.xenproject.org/2018/01/04/xen-project-spectremeltdown-faq/
33 comments
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.
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.
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.
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.
>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.
>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.
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.
This is incorrect: the BTB can be poisoned to speculatively jump anywhere in the text segment of the supervisor.
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...
"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."
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...
"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."
This depends on what you consider 'big'.
To me, the 'biggest' problem here is Spectre which affects all modern high-performance processors, regardless of make or model due to it being a failure of a fundamental technique used to create them.
The Meltdown bug is not more serious than Spectre, if anything, its the reverse as Meltdown has a realistic mitigation.
I see no attempt by Intel to minimise this as it quite clearly is an industry-wide problem, don't start looking for scapegoats where there is none.
There isn't always someone at fault.
To me, the 'biggest' problem here is Spectre which affects all modern high-performance processors, regardless of make or model due to it being a failure of a fundamental technique used to create them.
The Meltdown bug is not more serious than Spectre, if anything, its the reverse as Meltdown has a realistic mitigation.
I see no attempt by Intel to minimise this as it quite clearly is an industry-wide problem, don't start looking for scapegoats where there is none.
There isn't always someone at fault.
Spectre is more difficult to exploit. Plus, as the top commenter said, it's more difficult/less effective to exploit it on AMD still.
The "worse" part of Spectre is mainly about the fact that it affects everyone (but not to the same degree). But on a per chip-maker basis, Intel is still getting the shortest end of the stick here.
The "worse" part of Spectre is mainly about the fact that it affects everyone (but not to the same degree). But on a per chip-maker basis, Intel is still getting the shortest end of the stick here.
It's definitely true that Meltdown is a more immediate problem--but Spectre is basically the problem that will last. We can move kernel memory into another process space, take the perf hit, and correct most of the meltdown problems.
Spectre style issues had JS pulling browser process memory using timing--the patches being "put every page in its own process" (Chrome) and "don't let people get accurate timings" (Firefox). They are way worse in the grand scheme of things, because even if they aren't as easy to exploit, they will continue to show up, probably for the foreseeable future (next 5-10 years), long after Meltdown is patched and old news.
Spectre style issues had JS pulling browser process memory using timing--the patches being "put every page in its own process" (Chrome) and "don't let people get accurate timings" (Firefox). They are way worse in the grand scheme of things, because even if they aren't as easy to exploit, they will continue to show up, probably for the foreseeable future (next 5-10 years), long after Meltdown is patched and old news.
What? The whole idea that you can run untrusted code on your machine in the same process as secure data is ridiculous.
Of course every website needs it's own process. It should really be in it's own VM too.
Of course every website needs it's own process. It should really be in it's own VM too.
Or how about we stop perusing services that demand that we run 200+k of JS just to look at a few lines of text and images?
If you haven't seen what nukeop is referring to, then you need to read the discussions listed at https://news.ycombinator.com/item?id=16076601 .
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.
Astroturfers would also apply.
https://en.wikipedia.org/wiki/Astroturfing
https://en.wikipedia.org/wiki/Astroturfing
"PR flacks" has a long and (dis?)honourable history http://www.edsonpr.com/NEWS/Cheklist_summer06.pdf
You meant "PR flaks"?
shills
goons
people.
assholes
[deleted]
Reading everyone's comments, knowing nothing about this stuff, I had a random question:
Does all this create an opportunity for another chip line (architecture) to capture some of the server market?
I'm thinking specifically of SPARC. How far behind is SPARC now? A decade? Is that gap surmountable?
Given that 1) both AMD and Intel have issues, and 2) the commentariat have written the variety of ARMs are a mess too, and 3) maybe the people who care (those with server farms) will mitigate risks by adding a completely different architecture to the mix (prefer hetero vs mono culture).
Just curious.
Does all this create an opportunity for another chip line (architecture) to capture some of the server market?
I'm thinking specifically of SPARC. How far behind is SPARC now? A decade? Is that gap surmountable?
Given that 1) both AMD and Intel have issues, and 2) the commentariat have written the variety of ARMs are a mess too, and 3) maybe the people who care (those with server farms) will mitigate risks by adding a completely different architecture to the mix (prefer hetero vs mono culture).
Just curious.
SPARC does speculative execution, so it would be vulnerable to Spectre too.
However, I believe Solaris uses separate address spaces for user and kernel on SPARC. So that should avoid meltdown at least.
Also, it is unclear whether it allows speculation beyond privilege boundaries and it is also unclear whether ordering semantics for memory are different enough to mitigate somewhat.
I wish I still had access to modern sparc hardware to find out.
While it’s best to assume everything is vulnerable unless proven otherwise I’d really like to see a thorough evaluation.
Also, it is unclear whether it allows speculation beyond privilege boundaries and it is also unclear whether ordering semantics for memory are different enough to mitigate somewhat.
I wish I still had access to modern sparc hardware to find out.
While it’s best to assume everything is vulnerable unless proven otherwise I’d really like to see a thorough evaluation.
Where is that AMD quote from? The "As shown" text does not appear on that web page.
In the Meltdown paper, the authors report that they couldn't yet make the proof-of-concept exploit work on AMD or ARM, despite having confirmed the general vulnerability on those processors. So based on current knowledge, AMD and ARM are vulnerable to Meltdown with quite a high probability.
In the Meltdown paper, the authors report that they couldn't yet make the proof-of-concept exploit work on AMD or ARM, despite having confirmed the general vulnerability on those processors. So based on current knowledge, AMD and ARM are vulnerable to Meltdown with quite a high probability.
Meltdown exploits Intel's branch predictor behavior which is not present in other manufacturers' CPUs.
Depends on what you mean by Meltdown. The paper defines Meltdown ambigiously, the author variously refer to the Meltdown attack, the Meltdown exploit (= PoC), the Meltdown bug (= vulnerability).
The current PoC created by the researchers doesn't work on other manufacturer's CPU's, but the vulnerability and the Meltdown class of attacks should work on other manufacturer's CPUs. Or at least we don't know any reason it shouldn't. The authors' "toy example" works on AMD and ARM too. (See the section 6.4 in the paper).
The current PoC created by the researchers doesn't work on other manufacturer's CPU's, but the vulnerability and the Meltdown class of attacks should work on other manufacturer's CPUs. Or at least we don't know any reason it shouldn't. The authors' "toy example" works on AMD and ARM too. (See the section 6.4 in the paper).
> 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?