3 ms·

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

by 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.
      - fsflover 6y ago
        Thank you for the interesting thoughts. > 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. The malicious party would have to compromise a lot of websites for that: https://www.qubes-os.org/faq/#should-i-trust-this-website https://www.qubes-os.org/faq/#should-i-trust-this-website. Apart from that, let's see what the developers will reply: https://qubes-os.discourse.group/t/there-is-no-way-to-validate-the-qubes-master-signing-key/1441 https://qubes-os.discourse.group/t/there-is-no-way-to-valida....
    - pabs3 6y ago
      Signatures should go from the devs keys to the master key, not the other way around.

by nullc 6y ago

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.
    - fsflover 6y ago
      Thank you for the interesting thoughts. > 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. The malicious party would have to compromise a lot of websites for that: https://www.qubes-os.org/faq/#should-i-trust-this-website https://www.qubes-os.org/faq/#should-i-trust-this-website. Apart from that, let's see what the developers will reply: https://qubes-os.discourse.group/t/there-is-no-way-to-validate-the-qubes-master-signing-key/1441 https://qubes-os.discourse.group/t/there-is-no-way-to-valida....
  - pabs3 6y ago
    Signatures should go from the devs keys to the master key, not the other way around.