7 ms·

This is a red herring. Where are all the people that are unsure of the security of virtualization? There is some Xen vulnerability every year that is the equiva

This is a red herring. Where are all the people that are unsure of the security of virtualization? There is some Xen vulnerability every year that is the equivalent of the house burning down, but where is the Azure support article that suggests disabling Xen? (Oh right, you can't.) I mean, the article is totally right of course, you shouldn't run untrusted code - THAT INCLUDES THE FREAKING HYPERVISOR.

api 5y ago
There's definitely a bias in security toward "sexy" vulnerabilities that are novel and creative but hard to exploit in practice vs boring "forgot to bounds check" or "off by one logic error" type vulnerabilities that are pervasive. SMT (a.k.a. hyperthreading) is kind of a security minefield, but so is out of order execution and crufty instruction sets like x86_64. But vulnerabilities of this sort tend to be hard to exploit in the wild. Not saying you shouldn't be concerned about them, but how concerned you are should depend on your threat model. If I were really paranoid and could pick I'd choose something like a low-power simple ARM or RISC-V core to do critical computation. Alternatively you could run your secure compute on any system as long as nobody is allowed to run any other code on that system or have physical access to it. BTW I am deeply surprised that there has never been a cloud hypervisor doomsday vulnerability that has brought down AWS or some other huge provider. Back when virtualization in the cloud got big I would have bet serious money that this would have happened by now.
- melolife 5y ago
  To quote James Mickens, "large swathes of the security community are fixated on avant-garde horrors such as the fact that, during solar eclipses, pacemakers can be remotely controlled with a garage door opener and a Pringles can."
  - sonicanatidae 5y ago
    Yeah, making a note of this quote. Thanks!
  - mwint 5y ago
    Is this real? Can I read research somewhere about this? Edit: Here’s the apparent source of the quote: https://scholar.harvard.edu/files/mickens/files/thisworldofours.pdf https://scholar.harvard.edu/files/mickens/files/thisworldofo...
- CalChris 5y ago
  > If I were really paranoid and could pick I'd choose something like a low-power simple ARM or RISC-V core to do critical computation. Isn't that what Apple does with its Secure Enclave processor?
- fpgaminer 5y ago
  > BTW I am deeply surprised that there has never been a cloud hypervisor doomsday vulnerability that has brought down AWS or some other huge provider. Back when virtualization in the cloud got big I would have bet serious money that this would have happened by now. Meh, the vast majority of rational hackers will just sell a zero day capable of doing that either to the vendor themselves or to a nation state for several million dollars. I suppose they could bring down AWS for "fun", or try to short Amazon's stock and make a personal profit, but the consequences of getting caught are devastating. Selling the vuln is practically risk free and nets life changing money.
- AnthonyMouse 5y ago
  > SMT (a.k.a. hyperthreading) is kind of a security minefield, but so is out of order execution and crufty instruction sets like x86_64. But vulnerabilities of this sort tend to be hard to exploit in the wild. I'm not sure this is even true, so much as that it's just easier to do it some other way. You could use speculative execution by measuring timing to extract secrets to get privilege escalation, but then you have to sit there with the CPU at 100% for ten minutes while doing timing statistics. Whereas you pull the latest 0-day off a list somewhere, and the target is going to install the patch tomorrow but hasn't yet, and that pops the system in less than a second. So people do that instead. > BTW I am deeply surprised that there has never been a cloud hypervisor doomsday vulnerability that has brought down AWS or some other huge provider. Back when virtualization in the cloud got big I would have bet serious money that this would have happened by now. The assumption there is that the goal of somebody who got in would be an externally visible denial of service, as opposed to e.g. data exfiltration which might never be detected.
  - notyourday 5y ago
    > You could use speculative execution by measuring timing to extract secrets to get privilege escalation, but then you have to sit there with the CPU at 100% for ten minutes while doing timing statistics. Code wins arguments: 1. provide the exploit code that does it i.e. I go to a website and it reads a content that I have in a different browser tab. 2. provide the exploit code that while running on one VM on a host that does not have mitigations enabled reads a value of a file in a different VM.
    - notyourday 5y ago
      As expected from the "security" experts -- it is all chicken little "Sky is falling" talk and zero demonstrations. This is why pretty much no one takes it seriously : it used to be that the fancy vulnerabilities came with a demo: $ ./some-exploit-code # some-exploit-code won the argument. No one could argue that it did not matter as anyone who managed to get code executed on a target server got #. These days we just get lots of "OMG! We are all going to get pwned!" handwaving and zero demonstration that can be done in front of execs.
- kongolongo 5y ago
  >BTW I am deeply surprised that there has never been a cloud hypervisor doomsday vulnerability that has brought down AWS or some other huge provider. Back when virtualization in the cloud got big I would have bet serious money that this would have happened by now. I think at this point anyone that's capable of launching such an attack would much rather it be as transparent as possible as they'd have far, far more to gain from not disrupting services. Aside from ransomware attacks, I think the general trend has always been towards those type of attacks as they're way more likely to be profitable
  - api 5y ago
    That may be very much the answer.
- staticassertion 5y ago
  > BTW I am deeply surprised that there has never been a cloud hypervisor doomsday vulnerability that has brought down AWS or some other huge provider. There have been multiple cases of significant vulnerabilities where cloud providers had to perform patching and restart their services. No one, to my knowledge, has exploited those maliciously, but the vulns have had impact.
acdha 5y ago
> (Oh right, you can't.) I think you inadvertently hit on why this is a good discussion to have: security is a concern across the entire stack and attackers have many points where they can successfully compromise your system. It's much harder to replace Xen than it is to disable SMT, so it's much more feasible for someone to consider the latter since it's a single configuration point with very little chance of side-effects other than cost whereas touching Xen would have massive ripple effects for ops & potentially compatibility.
- maerF0x0 5y ago
  > so it's much more feasible for someone to consider the latter And conversely it's much more beneficial for an attacker to consider the former (attacking the hypervisor), this exacerbates the situation by making red team more aggressive to one side whilst blue team is busy debating if they should disable SMT .
  - acdha 5y ago
    I mean, that's always possible but it was always the case that the blue team needs to worry about the entire stack and one of those two choices has several orders of magnitude more work involved. The blue team could disable SMT and switch back to debating Xen with almost no discernible impact on the time needed for the latter and an entire branch of the threat tree removed.
beebmam 5y ago
Does Azure even use Xen? I was under the assumption they used Hyper-V for virtualization of hosts
- hansel_der 5y ago
  idk but would not be surprised if every popular hypervisor out there is a descendant of xen
- angry_octet 5y ago
  You can run Xen under Hyper-V.
upofadown 5y ago
This would be an issue where no virtualisation was done at all. In perhaps some sort of critical situation where the rsk of virtualisation was unacceptable. So the subject of virtualisation is, well, a red herring.
deleted 5y ago
[deleted]
Spooky23 5y ago
Hyper-threading guidance has been to disable for a long time in security sensitive environments. Spectre/etc reinforced that.
deleted 5y ago
[deleted]
formerly_proven 5y ago
https://marc.info/?l=openbsd-misc&m=119318909016582 https://marc.info/?l=openbsd-misc&m=119318909016582

api 5y ago

There's definitely a bias in security toward "sexy" vulnerabilities that are novel and creative but hard to exploit in practice vs boring "forgot to bounds check" or "off by one logic error" type vulnerabilities that are pervasive. SMT (a.k.a. hyperthreading) is kind of a security minefield, but so is out of order execution and crufty instruction sets like x86_64. But vulnerabilities of this sort tend to be hard to exploit in the wild. Not saying you shouldn't be concerned about them, but how concerned you are should depend on your threat model. If I were really paranoid and could pick I'd choose something like a low-power simple ARM or RISC-V core to do critical computation. Alternatively you could run your secure compute on any system as long as nobody is allowed to run any other code on that system or have physical access to it. BTW I am deeply surprised that there has never been a cloud hypervisor doomsday vulnerability that has brought down AWS or some other huge provider. Back when virtualization in the cloud got big I would have bet serious money that this would have happened by now.

melolife 5y ago
To quote James Mickens, "large swathes of the security community are fixated on avant-garde horrors such as the fact that, during solar eclipses, pacemakers can be remotely controlled with a garage door opener and a Pringles can."
- sonicanatidae 5y ago
  Yeah, making a note of this quote. Thanks!
- mwint 5y ago
  Is this real? Can I read research somewhere about this? Edit: Here’s the apparent source of the quote: https://scholar.harvard.edu/files/mickens/files/thisworldofours.pdf https://scholar.harvard.edu/files/mickens/files/thisworldofo...
CalChris 5y ago
> If I were really paranoid and could pick I'd choose something like a low-power simple ARM or RISC-V core to do critical computation. Isn't that what Apple does with its Secure Enclave processor?
fpgaminer 5y ago
> BTW I am deeply surprised that there has never been a cloud hypervisor doomsday vulnerability that has brought down AWS or some other huge provider. Back when virtualization in the cloud got big I would have bet serious money that this would have happened by now. Meh, the vast majority of rational hackers will just sell a zero day capable of doing that either to the vendor themselves or to a nation state for several million dollars. I suppose they could bring down AWS for "fun", or try to short Amazon's stock and make a personal profit, but the consequences of getting caught are devastating. Selling the vuln is practically risk free and nets life changing money.
AnthonyMouse 5y ago
> SMT (a.k.a. hyperthreading) is kind of a security minefield, but so is out of order execution and crufty instruction sets like x86_64. But vulnerabilities of this sort tend to be hard to exploit in the wild. I'm not sure this is even true, so much as that it's just easier to do it some other way. You could use speculative execution by measuring timing to extract secrets to get privilege escalation, but then you have to sit there with the CPU at 100% for ten minutes while doing timing statistics. Whereas you pull the latest 0-day off a list somewhere, and the target is going to install the patch tomorrow but hasn't yet, and that pops the system in less than a second. So people do that instead. > BTW I am deeply surprised that there has never been a cloud hypervisor doomsday vulnerability that has brought down AWS or some other huge provider. Back when virtualization in the cloud got big I would have bet serious money that this would have happened by now. The assumption there is that the goal of somebody who got in would be an externally visible denial of service, as opposed to e.g. data exfiltration which might never be detected.
- notyourday 5y ago
  > You could use speculative execution by measuring timing to extract secrets to get privilege escalation, but then you have to sit there with the CPU at 100% for ten minutes while doing timing statistics. Code wins arguments: 1. provide the exploit code that does it i.e. I go to a website and it reads a content that I have in a different browser tab. 2. provide the exploit code that while running on one VM on a host that does not have mitigations enabled reads a value of a file in a different VM.
  - notyourday 5y ago
    As expected from the "security" experts -- it is all chicken little "Sky is falling" talk and zero demonstrations. This is why pretty much no one takes it seriously : it used to be that the fancy vulnerabilities came with a demo: $ ./some-exploit-code # some-exploit-code won the argument. No one could argue that it did not matter as anyone who managed to get code executed on a target server got #. These days we just get lots of "OMG! We are all going to get pwned!" handwaving and zero demonstration that can be done in front of execs.
kongolongo 5y ago
>BTW I am deeply surprised that there has never been a cloud hypervisor doomsday vulnerability that has brought down AWS or some other huge provider. Back when virtualization in the cloud got big I would have bet serious money that this would have happened by now. I think at this point anyone that's capable of launching such an attack would much rather it be as transparent as possible as they'd have far, far more to gain from not disrupting services. Aside from ransomware attacks, I think the general trend has always been towards those type of attacks as they're way more likely to be profitable
- api 5y ago
  That may be very much the answer.
staticassertion 5y ago
> BTW I am deeply surprised that there has never been a cloud hypervisor doomsday vulnerability that has brought down AWS or some other huge provider. There have been multiple cases of significant vulnerabilities where cloud providers had to perform patching and restart their services. No one, to my knowledge, has exploited those maliciously, but the vulns have had impact.

acdha 5y ago

> (Oh right, you can't.) I think you inadvertently hit on why this is a good discussion to have: security is a concern across the entire stack and attackers have many points where they can successfully compromise your system. It's much harder to replace Xen than it is to disable SMT, so it's much more feasible for someone to consider the latter since it's a single configuration point with very little chance of side-effects other than cost whereas touching Xen would have massive ripple effects for ops & potentially compatibility.

maerF0x0 5y ago
> so it's much more feasible for someone to consider the latter And conversely it's much more beneficial for an attacker to consider the former (attacking the hypervisor), this exacerbates the situation by making red team more aggressive to one side whilst blue team is busy debating if they should disable SMT .
- acdha 5y ago
  I mean, that's always possible but it was always the case that the blue team needs to worry about the entire stack and one of those two choices has several orders of magnitude more work involved. The blue team could disable SMT and switch back to debating Xen with almost no discernible impact on the time needed for the latter and an entire branch of the threat tree removed.

beebmam 5y ago

Does Azure even use Xen? I was under the assumption they used Hyper-V for virtualization of hosts

hansel_der 5y ago
idk but would not be surprised if every popular hypervisor out there is a descendant of xen
angry_octet 5y ago
You can run Xen under Hyper-V.

upofadown 5y ago

This would be an issue where no virtualisation was done at all. In perhaps some sort of critical situation where the rsk of virtualisation was unacceptable. So the subject of virtualisation is, well, a red herring.

deleted 5y ago

[deleted]

Spooky23 5y ago

Hyper-threading guidance has been to disable for a long time in security sensitive environments. Spectre/etc reinforced that.

deleted 5y ago

[deleted]

formerly_proven 5y ago

https://marc.info/?l=openbsd-misc&m=119318909016582 https://marc.info/?l=openbsd-misc&m=119318909016582