5 ms·

>virtually impossible >NSA I have a bridge to sell.

by tucnak 3y ago

fsflover 3y ago
I'm not aware of any escape since Blue Pill in 2006, found by the Qubes founder herself.
- tucnak 3y ago
  Which is indicative of... squat. They could introduce an RSA-authenticated backdoor at any time, not unlike the one we had seen in xz, & no researcher would ever find out. In fact, chances are it's already there but even if it's not, Qubes is locking you into Xen platform regardless. The only viable means of gaining security against the NSA is full-source bootstrap from commodity FPGAs. Yes, you'll be stuck at 50 MHz for the time being but at least you know a backdoor-in-synthesis is so much more intractable. The physical surface area to protect is much smaller, too.
  - greggsy 3y ago
    The complexity involved in targeting distributed, temporal backend systems like the ones being discussed here is sufficiently unreliable and risky that it’s easier and cheaper to just go straight for the people, or simply find another avenue.
- Veserv 3y ago
  Really? I typed “Xen VM Escape” into Google and this is the first hit mentioning at least 4 critical escapes between 2015 and 2017. https://www.csoonline.com/article/561467/xen-hypervisor-faces-third-highly-critical-vm-escape-bug-in-10-months.html https://www.csoonline.com/article/561467/xen-hypervisor-face... You did not even try to confirm if what you said is true.
  - fsflover 3y ago
    Since release 4.0, Qubes is not just Xen. It relies on VT-d, which is hardware-assisted virtualization. The escapes you mentioned were the main reason to do it. More info: https://github.com/QubesOS/qubes-secpack/blob/master/QSBs/qsb-030-2017.txt https://github.com/QubesOS/qubes-secpack/blob/master/QSBs/qs...
    - Veserv 3y ago
      Did you know about this previously? Then why did you lie previously claiming there have been no escapes? If you did not know about this previously, then why should I believe someone who boldly asserted that a system was "virtually impossible to break", despite the fact that your average developer would laugh at the idea such a thing exists, and was then trivially proven to have no idea what they were talking about, but has now backpedaled to a different stance after some hasty research? For that matter, even if I take your statements at face value, why would a design goal have any impact on the security of a system. Those are called goals, you can fail to reach them. You need to present verification and audits that the goals were achieved. Given that you literally can not name a single other piece of software that has achieved the goal of "virtually impossible to break" (except by absence of evidence), you can not just assume such a goal is achieved. Given that we are talking about press organizations that are regularly attacked by state actors, "virtually impossible" in this context means it needs to be proof against state actors. So please present literally anybody who claims that state actors such as the NSA can not breach a Qubes system, then you can present their evidence. I am certain not even Joanna would make such a ridiculous claim and would shoot down anybody on the development team who tried to make such a claim. There is a reason their tagline is "A Reasonably Secure Operating System", not a "Virtually Impossible to Break Operating System". They know it is not proof against state actors and they have the honesty to say that unlike the snake oil peddlers commonly seen in cybersecurity.
      - fsflover 3y ago
        > Did you know about this previously? Then why did you lie previously claiming there have been no escapes? Yes, I knew. In the context of this article, we are talking here about the currently supported Qubes release (4.2), which implemented the new virtualization mechanism. The latter was not broken in your links, or anywhere else after 2006. It's not a design goal but actually working implementation at present. > "virtually impossible" in this context means it needs to be proof against state actors First of all, nothing is 100% proof against state actors, because they can use completely different attack vectors. I just believe that the VM escape attack vector is extremely unlikely in this case, and I rely on the lack of known escapes to make this conclusion, which should have been clear from my comments.

>virtually impossible >NSA I have a bridge to sell.

by tucnak 3y ago

>virtually impossible >NSA I have a bridge to sell.

fsflover 3y ago

I'm not aware of any escape since Blue Pill in 2006, found by the Qubes founder herself.

tucnak 3y ago
Which is indicative of... squat. They could introduce an RSA-authenticated backdoor at any time, not unlike the one we had seen in xz, & no researcher would ever find out. In fact, chances are it's already there but even if it's not, Qubes is locking you into Xen platform regardless. The only viable means of gaining security against the NSA is full-source bootstrap from commodity FPGAs. Yes, you'll be stuck at 50 MHz for the time being but at least you know a backdoor-in-synthesis is so much more intractable. The physical surface area to protect is much smaller, too.
- greggsy 3y ago
  The complexity involved in targeting distributed, temporal backend systems like the ones being discussed here is sufficiently unreliable and risky that it’s easier and cheaper to just go straight for the people, or simply find another avenue.
Veserv 3y ago
Really? I typed “Xen VM Escape” into Google and this is the first hit mentioning at least 4 critical escapes between 2015 and 2017. https://www.csoonline.com/article/561467/xen-hypervisor-faces-third-highly-critical-vm-escape-bug-in-10-months.html https://www.csoonline.com/article/561467/xen-hypervisor-face... You did not even try to confirm if what you said is true.
- fsflover 3y ago
  Since release 4.0, Qubes is not just Xen. It relies on VT-d, which is hardware-assisted virtualization. The escapes you mentioned were the main reason to do it. More info: https://github.com/QubesOS/qubes-secpack/blob/master/QSBs/qsb-030-2017.txt https://github.com/QubesOS/qubes-secpack/blob/master/QSBs/qs...
  - Veserv 3y ago
    Did you know about this previously? Then why did you lie previously claiming there have been no escapes? If you did not know about this previously, then why should I believe someone who boldly asserted that a system was "virtually impossible to break", despite the fact that your average developer would laugh at the idea such a thing exists, and was then trivially proven to have no idea what they were talking about, but has now backpedaled to a different stance after some hasty research? For that matter, even if I take your statements at face value, why would a design goal have any impact on the security of a system. Those are called goals, you can fail to reach them. You need to present verification and audits that the goals were achieved. Given that you literally can not name a single other piece of software that has achieved the goal of "virtually impossible to break" (except by absence of evidence), you can not just assume such a goal is achieved. Given that we are talking about press organizations that are regularly attacked by state actors, "virtually impossible" in this context means it needs to be proof against state actors. So please present literally anybody who claims that state actors such as the NSA can not breach a Qubes system, then you can present their evidence. I am certain not even Joanna would make such a ridiculous claim and would shoot down anybody on the development team who tried to make such a claim. There is a reason their tagline is "A Reasonably Secure Operating System", not a "Virtually Impossible to Break Operating System". They know it is not proof against state actors and they have the honesty to say that unlike the snake oil peddlers commonly seen in cybersecurity.
    - fsflover 3y ago
      > Did you know about this previously? Then why did you lie previously claiming there have been no escapes? Yes, I knew. In the context of this article, we are talking here about the currently supported Qubes release (4.2), which implemented the new virtualization mechanism. The latter was not broken in your links, or anywhere else after 2006. It's not a design goal but actually working implementation at present. > "virtually impossible" in this context means it needs to be proof against state actors First of all, nothing is 100% proof against state actors, because they can use completely different attack vectors. I just believe that the VM escape attack vector is extremely unlikely in this case, and I rely on the lack of known escapes to make this conclusion, which should have been clear from my comments.