7 ms·

Xen Project Spectre/Meltdown FAQ

139 points by r4um 9y ago

weinzierl 9y ago
> 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 9y ago
  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.
nukeop 9y ago
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-privileged-memory-with-side.html 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."
- TickleSteve 9y ago
  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.
  - JdeBP 9y ago
    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 https://news.ycombinator.com/item?id=16076601 .
  - mtgx 9y ago
    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.
    - electronvolt 9y ago
      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.
fyi1183 9y ago
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.
lowbloodsugar 9y ago
>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.

139 points by r4um 9y ago

> 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 9y ago
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.

nukeop 9y ago

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-privileged-memory-with-side.html 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."

TickleSteve 9y ago
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.
- JdeBP 9y ago
  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 https://news.ycombinator.com/item?id=16076601 .
- mtgx 9y ago
  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.
  - electronvolt 9y ago
    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.

fyi1183 9y ago

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.

lowbloodsugar 9y ago

>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.