4 ms·

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/a

by 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.
    - Veserv 3y ago
      Point to literally anybody on the development team who claims it can stop a small team of professionals with a 10 M$ budget from finding a remote exploit. That is a tiny fraction of what a state actor can deploy and constitutes at best a low-end attack by a state actor who is actually targeting you. Just for reference, we can peg that at a first-order estimate of 40,000 person-hours or about 20 person-years, so a team of 20 with a whole calendar year to work full-time on finding a remote exploit. Even the developers themselves do not think they can provide protection against such low-end attacks. I mean, seriously, find me a single person in the entire world doing offensive cybersecurity research who thinks there is any system in the entire world that can stop any team with a 10 M$ budget. Find me any single person in the entire world doing cybersecurity that would place a open bet that they could stop any team with a 10 M$ payout. I am certain you would be laughed out of the room in the former, and you would see dollar signs in their eyes if you introduced them to the latter. Stop propagating marketing fluff. That is not to say that Qubes is horribly insecure. It is just not even close to "virtually impossible to break". And, to their credit, they are honest and very clear about this in their messaging and should be applauded for it unlike actual bad actors like Crowdstrike, Microsoft, Apple, Palo Alto Networks, Google, Sentinel One, (basically everybody) etc. who just make up whatever security bullshit to push product. It, however, does no good to make up random hyperbole with no basis in fact for products that are actually being careful to not overpromise. Frankly, it is doing the team at Qubes a disservice because people will hear the nonsense and then get burned and blame Qubes even though they were careful to honestly express the limitations.

by Veserv 3y ago

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.
  - Veserv 3y ago
    Point to literally anybody on the development team who claims it can stop a small team of professionals with a 10 M$ budget from finding a remote exploit. That is a tiny fraction of what a state actor can deploy and constitutes at best a low-end attack by a state actor who is actually targeting you. Just for reference, we can peg that at a first-order estimate of 40,000 person-hours or about 20 person-years, so a team of 20 with a whole calendar year to work full-time on finding a remote exploit. Even the developers themselves do not think they can provide protection against such low-end attacks. I mean, seriously, find me a single person in the entire world doing offensive cybersecurity research who thinks there is any system in the entire world that can stop any team with a 10 M$ budget. Find me any single person in the entire world doing cybersecurity that would place a open bet that they could stop any team with a 10 M$ payout. I am certain you would be laughed out of the room in the former, and you would see dollar signs in their eyes if you introduced them to the latter. Stop propagating marketing fluff. That is not to say that Qubes is horribly insecure. It is just not even close to "virtually impossible to break". And, to their credit, they are honest and very clear about this in their messaging and should be applauded for it unlike actual bad actors like Crowdstrike, Microsoft, Apple, Palo Alto Networks, Google, Sentinel One, (basically everybody) etc. who just make up whatever security bullshit to push product. It, however, does no good to make up random hyperbole with no basis in fact for products that are actually being careful to not overpromise. Frankly, it is doing the team at Qubes a disservice because people will hear the nonsense and then get burned and blame Qubes even though they were careful to honestly express the limitations.