Due to the security problems described in QSB-091, installation of Qubes Windows Tools is currently blocked. … While Windows qubes are, in Qubes, generally not regarded as being very trustworthy, a possible compromise of the Xen drivers used in Qubes Windows Tools might create a risk for Xen or dom0 and thus be dangerous for Qubes itself.
However when I go to QSB-091 and read from there, it says:
If the Xen Project’s Windows PV Drivers were compromised at build time,
all Windows qubes that have Qubes Windows Tools (QWT) installed may also
be compromised. If the drivers were not compromised at build time, then
there is no known vulnerability.
Dom0 is not affected, even though the qubes-windows-tools package is
installed in dom0, since neither the dom0 package build process nor dom0
itself interprets these driver files. Rather, the purpose of this
package is merely to make the driver files available to the Windows
qubes in which QWT are installed.
So, which is it? Are the windows tools a danger to the highly trusted sections of Qubes and Xen, or is it localized only to the windows installations to which it’s installed? Do I need to worry that my windows qube, by virtue of having these tools installed, can potentially read information off of my banking or password management qubes? What exactly is the threat here?
I think this can be said for any other software installed in a qube as well, but this was mentioned for QWT specifically because if the Xen drivers in QWT were really compromised then the probability of QWT containing some exploit that can break the Xen virtualization is much higher than some other random software.
Yeah the windows qube in question is of minimal trust. That’s why I don’t really mind installing potentially compromised software on it, as windows itself can be considered compromised. I’m trying to gauge the risk to the rest of my system.
The QSB is correct. The windows doc page may be misleading, depending on how you interpret it.
In general, QSBs take precedence over the docs in the case of any conflict (which is rare), because QSBs are signed directly by the Qubes security team.
(Doc changes are also vetted, and every change must be signed by a Qubes team member, but the security team doesn’t have the capacity to review every doc change.)
QWT is installed in dom0.
The security model of Qubes entails that malicious software should be able to be installed in a domU without compromising the rest of the system.
You’re right that malware designed specifically for Qubes OS is more likely to feature a Xen hypervisor exploit than random malware, but that’s simply because most OSes don’t use the Xen hypervisor as part of the OS. But still, the software doesn’t have to advertise itself as being for Qubes OS (the way QWT does) in order to contain Qubes-targeting malware (though I guess this might make it more likely to reach its intended target).
That’s a good point that the security model of Qubes relies on the safety of running malicious code in domUs. If we assume a particular qube’s exploit can spread to the rest of the system, the whole security model crumbles.
Perhaps the documentation was referring to a hypothetical exploit targetting Qubes users, like your point 3. Theoretically if an exploit in Xen exists that can be exploited by the Xen drivers, and this exploit is known by people who have control over those drivers, who also wish to cause harm to Qubes users, in a way that is not detected by anyone in the community, then this could possibly be a risk. Perhaps that’s a bit of a stretch.
Though I can see how it can be more risky than running unrelated malware. If I saw someone advertising “Hey Qubes users! Come run this!” I’d be highly suspicious and would probably avoid running it even inside of a qube.
