6 ms·

Let's compare this to QubesOS: Which adversary can hack QubesOS while not being able to hack this ?

by petra 6y ago

nullc 6y ago
If I have control of QuebesOS' ISP -- it's pretty easy to "hack" Qubes, sadly: There is pretty much no way to validate the qubes public keys, they're not signed by anything else. So the software can be substituted when you download it. More along the lines of what you're asking-- the virtualization creates a huge attack surface and there is a long history of VM escapes, microarch sidechannels, etc.
- fsflover 6y ago
  Qubes OS v4+ does not use typical software virtualization methods. VT-d hardware virtualization it uses was broken only once, and it was done by the Qubes founder: https://en.wikipedia.org/wiki/Blue_Pill_(software) https://en.wikipedia.org/wiki/Blue_Pill_(software) >There is pretty much no way to validate the qubes public keys, they're not signed by anything else. Not sure what you mean here. All Qubes keys are signed by the master key which belongs to the main developers.
  - nullc 6y ago
    > it uses was broken only once, and it was done by the Qubes founder Well, not quite: > "XSA-213 is a fatal, reliably exploitable bug in Xen," said the security team of Qubes OS, an operating system that isolates applications inside Xen virtual machines. "In the nearly eight-year history of the Qubes OS project, we have become aware of four bugs of this calibre: XSA-148, XSA-182, XSA-212 and now XSA-213." https://www.csoonline.com/article/3193718/xen-hypervisor-faces-third-highly-critical-vm-escape-bug-in-10-months.html https://www.csoonline.com/article/3193718/xen-hypervisor-fac... > Qubes keys are signed by the master key which belongs to the main developers. Right, and that master key is signed by nothing. There is no way provided to verify it.
    - fsflover 6y ago
      > https://www.csoonline.com/article/3193718/xen-hypervisor-faces-third-highly-critical-vm-escape-bug-in-10-months.html https://www.csoonline.com/article/3193718/xen-hypervisor-fac... > May 3, 2017 I said Qubes 4+, which was released in 2018: https://www.qubes-os.org/news/2018/03/28/qubes-40/ https://www.qubes-os.org/news/2018/03/28/qubes-40/. All previous versions relied on software virtualization (and had much wider compatible hardware). > Right, and that master key is signed by nothing. There is no way provided to verify it. Sorry for my ignorance, how does one securely verify a master key not risking to compromise it?
      - pabs3 6y ago
        Those with knowledge of what the master key is sign the master key, those with knowledge of those people and their keys sign those keys, and so on and so on until you have signed one of the keys in the set. Aka, "the web of trust".
        fsflover 6y ago
        The Qubes Master Signing Key is kept on air-gapped machine accessible only to the developers. It signs their keys and the fact that they are signed by it is already the evidence of its validity. It's set to never expire and so it is extremely sensitive. I don't see how you can make it better in terms of security. https://www.qubes-os.org/security/verifying-signatures/#1-get-the-qubes-master-signing-key-and-verify-its-authenticity https://www.qubes-os.org/security/verifying-signatures/#1-ge...
        nullc 6y ago
        By making it so that people can securely receive it. If Qubes ISP is malicious or compromised they can intercept http connections towards Qubes' servers. This allows them to trivially obtain a SSL cert for keys.qubes-os.org, etc. Armed with a valid SSL cert, they MITM traffic. When a target downloads qubes they give them a tampered version, when a target downloads the master key, they give them a lookalike key. The user can happily verify the tampered qubes with the lookalike key. PGP proves nothing if you cannot verify that you have an authentic copy of the key. Qubes gives some handwavy suggestions at how to check the key which do not work. The first item "Use the PGP Web of Trust." cannot be done because the key isn't signed by anyone. The other suggestions are inapplicable or won't achieve anything if the target's network is being tampered with. This is not some newfangled problem. PGP has the ability to sign keys for precisely this reason. The main Qubes developers should have personal PGP keys which they use to sign the master key. Their personal keys should be certified by other FOSS developers that they've met (maybe the master key too). Then people who are interested in obtaining high confidence in the key can inspect the chain from their own key to the qubes masterkey. Obviously not everyone will perform careful validation, but if some do then substituting the key becomes riskier. Unfortunately not only is the key not verifiable at the moment, but the current situation is looks pretty similar to what an ongoing key replacement attack would look like.
  - Retr0spectrum 6y ago
    VT-x itself is not the main attack surface. It's all the interfaces between the inside and the outside of the VMs, for example graphics hardware emulation, network hardware emulation, etc. etc. There have been many of these bugs, on qubes/xen, and basically every other popular hypervisor. I have personally found a kernel memory disclosure vulnerability affecting xen, which I tested under qubes (it wasn't a very useful bug, but the point is, they exist and they are plentiful). Furthermore, the "blue pill" attack is not a vulnerability in VT-x itself. In fact, it does not exploit any vulnerabilities at all - it simply works off the idea that code running in ring n can hide itself from code running ring+1 (the bluepill hypervisor being ring -1).
    - fsflover 6y ago
      Those bugs of course exist, but I would not say "There have been many of these bugs, on qubes/xen... they exist and they are plentiful": https://www.qubes-os.org/security/xsa/ https://www.qubes-os.org/security/xsa/. The actual number is 67 in ~10 years: https://www.qubes-os.org/security/xsa/ https://www.qubes-os.org/security/xsa/, which is more secure than anything else AFAIK. Note, this is counting older Qubes versions, where the virtualization was much less secure.
fsflover 6y ago
Intel: https://en.wikipedia.org/wiki/Intel_Management_Engine https://en.wikipedia.org/wiki/Intel_Management_Engine

Let's compare this to QubesOS: Which adversary can hack QubesOS while not being able to hack this ?

by petra 6y ago

Let's compare this to QubesOS: Which adversary can hack QubesOS while not being able to hack this ?

If I have control of QuebesOS' ISP -- it's pretty easy to "hack" Qubes, sadly: There is pretty much no way to validate the qubes public keys, they're not signed by anything else. So the software can be substituted when you download it. More along the lines of what you're asking-- the virtualization creates a huge attack surface and there is a long history of VM escapes, microarch sidechannels, etc.

fsflover 6y ago
Qubes OS v4+ does not use typical software virtualization methods. VT-d hardware virtualization it uses was broken only once, and it was done by the Qubes founder: https://en.wikipedia.org/wiki/Blue_Pill_(software) https://en.wikipedia.org/wiki/Blue_Pill_(software) >There is pretty much no way to validate the qubes public keys, they're not signed by anything else. Not sure what you mean here. All Qubes keys are signed by the master key which belongs to the main developers.
- nullc 6y ago
  > it uses was broken only once, and it was done by the Qubes founder Well, not quite: > "XSA-213 is a fatal, reliably exploitable bug in Xen," said the security team of Qubes OS, an operating system that isolates applications inside Xen virtual machines. "In the nearly eight-year history of the Qubes OS project, we have become aware of four bugs of this calibre: XSA-148, XSA-182, XSA-212 and now XSA-213." https://www.csoonline.com/article/3193718/xen-hypervisor-faces-third-highly-critical-vm-escape-bug-in-10-months.html https://www.csoonline.com/article/3193718/xen-hypervisor-fac... > Qubes keys are signed by the master key which belongs to the main developers. Right, and that master key is signed by nothing. There is no way provided to verify it.
  - fsflover 6y ago
    > https://www.csoonline.com/article/3193718/xen-hypervisor-faces-third-highly-critical-vm-escape-bug-in-10-months.html https://www.csoonline.com/article/3193718/xen-hypervisor-fac... > May 3, 2017 I said Qubes 4+, which was released in 2018: https://www.qubes-os.org/news/2018/03/28/qubes-40/ https://www.qubes-os.org/news/2018/03/28/qubes-40/. All previous versions relied on software virtualization (and had much wider compatible hardware). > Right, and that master key is signed by nothing. There is no way provided to verify it. Sorry for my ignorance, how does one securely verify a master key not risking to compromise it?
    - pabs3 6y ago
      Those with knowledge of what the master key is sign the master key, those with knowledge of those people and their keys sign those keys, and so on and so on until you have signed one of the keys in the set. Aka, "the web of trust".
      - fsflover 6y ago
        The Qubes Master Signing Key is kept on air-gapped machine accessible only to the developers. It signs their keys and the fact that they are signed by it is already the evidence of its validity. It's set to never expire and so it is extremely sensitive. I don't see how you can make it better in terms of security. https://www.qubes-os.org/security/verifying-signatures/#1-get-the-qubes-master-signing-key-and-verify-its-authenticity https://www.qubes-os.org/security/verifying-signatures/#1-ge...
        nullc 6y ago
        By making it so that people can securely receive it. If Qubes ISP is malicious or compromised they can intercept http connections towards Qubes' servers. This allows them to trivially obtain a SSL cert for keys.qubes-os.org, etc. Armed with a valid SSL cert, they MITM traffic. When a target downloads qubes they give them a tampered version, when a target downloads the master key, they give them a lookalike key. The user can happily verify the tampered qubes with the lookalike key. PGP proves nothing if you cannot verify that you have an authentic copy of the key. Qubes gives some handwavy suggestions at how to check the key which do not work. The first item "Use the PGP Web of Trust." cannot be done because the key isn't signed by anyone. The other suggestions are inapplicable or won't achieve anything if the target's network is being tampered with. This is not some newfangled problem. PGP has the ability to sign keys for precisely this reason. The main Qubes developers should have personal PGP keys which they use to sign the master key. Their personal keys should be certified by other FOSS developers that they've met (maybe the master key too). Then people who are interested in obtaining high confidence in the key can inspect the chain from their own key to the qubes masterkey. Obviously not everyone will perform careful validation, but if some do then substituting the key becomes riskier. Unfortunately not only is the key not verifiable at the moment, but the current situation is looks pretty similar to what an ongoing key replacement attack would look like.
- Retr0spectrum 6y ago
  VT-x itself is not the main attack surface. It's all the interfaces between the inside and the outside of the VMs, for example graphics hardware emulation, network hardware emulation, etc. etc. There have been many of these bugs, on qubes/xen, and basically every other popular hypervisor. I have personally found a kernel memory disclosure vulnerability affecting xen, which I tested under qubes (it wasn't a very useful bug, but the point is, they exist and they are plentiful). Furthermore, the "blue pill" attack is not a vulnerability in VT-x itself. In fact, it does not exploit any vulnerabilities at all - it simply works off the idea that code running in ring n can hide itself from code running ring+1 (the bluepill hypervisor being ring -1).
  - fsflover 6y ago
    Those bugs of course exist, but I would not say "There have been many of these bugs, on qubes/xen... they exist and they are plentiful": https://www.qubes-os.org/security/xsa/ https://www.qubes-os.org/security/xsa/. The actual number is 67 in ~10 years: https://www.qubes-os.org/security/xsa/ https://www.qubes-os.org/security/xsa/, which is more secure than anything else AFAIK. Note, this is counting older Qubes versions, where the virtualization was much less secure.

fsflover 6y ago

Intel: https://en.wikipedia.org/wiki/Intel_Management_Engine https://en.wikipedia.org/wiki/Intel_Management_Engine