Qubes R4.2 EOL: No upgrade path for installations with Windows and QWT

[Gerhard Weck]

Currently, there does not seem to be a working way to run Windows VMs using Qubes Windows Tools under Qubes R4.2.1. So putting Qubes R4.1.2 to EOL forces installations with such qubes to select one of the following two alternatives: either discontinue the use of Qubes as a protective shield for Windows or use a deprecated version of Qubes. Both have to be regarded as a regression.

Windows qubes imported from R4.1.2 to R4.2.1 should retain their complete functionality or, alternatively, EOL of R4.2.1 should be postponed until such functionality is available under Qubes R4.2.1.

This problem may be solved if Qubes issue #1861 is completed before the scheduled EOL for R4.1.

[unman]

> <https://github.com/QubesOS/qubes-issues/issues/1861> is completed before

> the scheduled EOL for R4.1.
>

The problem is that the QWT are currently insecure. It seems
unreasonable to suggest that Qubes should allow users to work with such
software.

In my view, if some software is deprecated or insecure, then it is
reasonable for it to be removed from a new release. This happens all the
time in other distributions, (and in Windows too.)

Is it true that there is no working way to use QWT, or is this an issue
with some aspects of the QWT, or is it specific to importing from 4.1
with some features enabled?
There are users of Windows in 4.2

--
I never presume to speak for the Qubes team.
When I comment in the mailing lists I speak for myself.

[jma...@tutanota.com]

Apr 11, 2024, 15:57 by qubes...@googlegroups.com:

> --
> You received this message because you are subscribed to the Google Groups "qubes-devel" group.
> To unsubscribe from this group and stop receiving emails from it, send an email to qubes-devel...@googlegroups.com.
> To view this discussion on the web visit https://groups.google.com/d/msgid/qubes-devel/ZhgIcbJLIq7eIYUa%40thirdeyesecurity.org.

>

> In my view, if some software is deprecated or insecure

@unman, do you mean "QWT is deprecated"? Otherwise why do you mention deprecation at all? Is it an opinion shared by the Team, too?


The current situation makes Qubes OS R4.2 the first version of Qubes OS that has such a bad Windows support on the release date.
And it also makes Qubes OS probably the worse operation system to have Windows running virtualized, because Qubes OS is Xen-based and it limits other nice options like running VirtualBox or any other solution to make Windows running well with comfort of clipboard sharing and other things.

It is unfortunate, because I love Qubes OS and back in the day Qubes OS was one of the best to run Windows virualized, because it had integrated clipboard transfer, seamless windows and other features of the system united in a similar over GNU/Linux and Windows.

All this being considered, I completely support Gerhard Weck. EOL of R4.1 should be postponed until restoring qubes and the whole Windows functionality is available under Qubes R4.2 or later releases.

Even more, I think that releasing R4.2 that is not able to run qubes created in the previous minor version R4.1 was not such a good idea. Almost all users won't be able to solve this situation themselves and they will have unusable backup of unbootable qube with their valuable data in it. From this point of view, R4.2, maybe, should not been released at all until packaging problems of QWT would be solved (as blocker?), to prevent users getting in such situations in the first place. Users are the most valuable part in the project, to my opinion.

[Gerhard Weck]

When the backup-restore of Windows VMs with QWT is blocked, the cure may be worse than the illness - the security problems of QWT -, as it makes usage of Qubes R4.2 impossible in this case. In order not to lose the data and functionality of these VMs, the user is forced to either stay at R4.1 or abandon Qubes usage altogether, which probably will be unacceptable from a security point of view.

Here one has to consider the risks coming from the security problems described in QSB-091 and evaluate them in the context of one's threat model.  This depends on several factors, some of which are unclear to me:

- The problems of the Xen PV drivers may lead to situations where the Windows VM could be compromised. This, however, will not be so automatic but will require an attacker who can insert and execute his/her own software in the VM. If the VM is used just locally without network access and usage of external data, there will be no such attacker, and the security implications of QSB-091 will not be relevant in such a scenario. In this case, blocking the restoration of the VM will reduce the overall security, as it blocks migration to R4.2.

- Even if such a Windows VM may be compromised, this may still be acceptable, if no sensitive data are processed there. In this case, too, it would be good to continue the usage of this VM under R4.2.

- Things may look different, if an attacker could, via the Xen PV drivers, break out of a Windows VM with QWT and compromise Xen, and therefore Qubes itself. In this case, usage of a Windows VM with the insecure QWT may be too risky in many, but not all circumstances. So far, I found no information, if such a scenario is possible at all. What is the extent of possible compromises of the Xen PV drivers - is it just local to the VM or could it reach into Qubes itself? It would be helpful if this could be clarified somehow.

The bottom line of this, however, is that the current state of completely blocking QWT usage and the transfer of Windows VMs with QWT from R4.1 to R4.2 probably creates more problems than it solves.

[Andrew David Wong]

On 4/12/24 4:50 AM, Gerhard Weck wrote:
> [...]

>
> - Things may look different, if an attacker could, via the Xen PV drivers,
> break out of a Windows VM with QWT and compromise Xen, and therefore Qubes
> itself. In this case, usage of a Windows VM with the insecure QWT may be
> too risky in many, but not all circumstances. So far, I found no
> information, if such a scenario is possible at all. What is the extent of
> possible compromises of the Xen PV drivers - is it just local to the VM or
> could it reach into Qubes itself? It would be helpful if this could be
> clarified somehow.
>

> [...]
>

This was already clearly addressed in QSB-091:

> Impact
> -------
>
> 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.

In other words, only the Windows VMs using QWT are potentially at risk, not dom0, Xen, or Qubes OS itself.

[Gerhard Weck]

Thank you for clarifying this!

So there is not much sense in blocking QWT, as Windows qubes are notoriously insecure. Using a compromised QWT will just make an already bad situation even worse. Using Windows under Qubes poses a risk anyhow, but this risk is mitigated a lot thanks to the security functions of Qubes.  Using Windows outside Qubes is, in my opinion, suicide, especially when you regard the latest problems like the Midnight Blizzard's hack.

[jma...@tutanota.com]

Apr 13, 2024, 06:46 by a...@qubes-os.org:

@adw , thank you. So, QWT does not directly affect security of dom0 nor other non-windows qubes.

Please also tell if QWT is deprecated, as unman kind of said, or not?

[Andrew David Wong]

This is also addressed in QSB-091:

> At the time of writing, the Xen Project has not published replacement
> binaries signed by a Microsoft-approved key. The process for doing this
> has changed since the last version of Windows PV Drivers was released,
> and we have no information as to whether or when new signed binaries
> will be available. [2]
>
> In order to avoid similar problems in the future, we are working on a
> more permanent solution regarding the need for signed PV drivers in QWT.
> In the meantime, we will replace the `qubes-windows-tools` package with
> a dummy package containing only warning text.

https://www.qubes-os.org/news/2023/07/27/qsb-091/

[jma...@tutanota.com]

Apr 13, 2024, 15:26 by a...@qubes-os.org:

Well, the link does not say the QWT is deprecated in any way. The only problem is that Qubes OS was not building some drivers using in QWT from sources but used Xen's binaries that are signed with Microsoft-approved key. Now Microsoft deprecated this way of signing, that's all. Deprecated signing approach by Microsoft have nothing to do with deprecation of available Xen drivers sources, nor QWT itself, if I am getting it correctly (I hope).

So, am I getting it right that QWT is not deprecated? I was afraid for a moment.
As it was discussed previously, the QWT package can be build from secure and available sources and put to R4.2+ repos with different signatures, including secure self-signed but not Microsoft-approved key. Requirement to allow self-signed drivers is not perfect, but still a way better solution than current situation, to my understanding.

I support the opinion that R4.1 cannot be EOLed before there would be a version of Qubes OS that is capable to restore and boot such windows qubes with valuable users' data in them.

[Andrew David Wong]

On 4/13/24 8:56 AM, jmake2 via qubes-devel wrote:
> [...]

>
> So, am I getting it right that QWT is not deprecated? I was afraid for a moment.

As stated in the QSB, the developers are still working on QWT, so it is not deprecated.

> As it was discussed previously, the QWT package can be build from secure and available sources and put to R4.2+ repos with different signatures, including secure self-signed but not Microsoft-approved key. Requirement to allow self-signed drivers is not perfect, but still a way better solution than current situation, to my understanding.
>

> [...]

I believe this is the relevant issue:

https://github.com/QubesOS/qubes-issues/issues/9019

[Gerhard Weck]

I think, here a word of caution is appropriate regarding the use of Microsoft-signed keys. As a current CISA report shows, there have been severe security breaches in the Microsft environment, and they are still continuing, as Microsoft does not seem able to kick the Russian Midnight Blizzard hackers out of its network. For this reason, one should not, security-wise, put too much (any?) trust into Mircosoft signatures of crypto keys, while, concerning QWT, their use is clearly convenient, as it removes the need for running Windows qubes with test-signing enabled.

But apart from that, I would trust the security management of Qubes itself much more, where the philosophy is based on not trusting the infrastructure, checking the code by the developers themselves and possibly by the community, and not relying on the security of some external agent.

[Hugo V.C.]

Interesting topic. I tried to use QWT long ago and, fortunately, didn't worked so since the very beginning I got used to use safer ways to copy files from my Windows to other qubes (I prefer not to give details here). In the last two years I have been tempted to debug what was happening with my QWT and trying to install them, but I always got a "feeling" that having those drivers was not a good idea. "Happy" to see I was right...

I think the current protocols for Windows drivers are not trustable thus I'll keep not installing them. Some bullet proof protocol should be created, otherwise it is impossible to get any trust. And this protocol must NOT depend on M$ nor on Qubes (wonderful) team. Something else.

--

You received this message because you are subscribed to the Google Groups "qubes-devel" group.
To unsubscribe from this group and stop receiving emails from it, send an email to qubes-devel...@googlegroups.com.

To view this discussion on the web visit https://groups.google.com/d/msgid/qubes-devel/860e2998-42c7-4912-a972-cbe841fa2000n%40googlegroups.com.

[jma...@tutanota.com]

Apr 14, 2024, 13:38 by skydi...@gmail.com:

> Interesting topic. I tried to use QWT long ago and, fortunately, didn't worked so since the very beginning I got used to use safer ways to copy files from my Windows to other qubes (I prefer not to give details here). In the last two years I have been tempted to debug what was happening with my QWT and trying to install them, but I always got a "feeling" that having those drivers was not a good idea. "Happy" to see I was right...
>
> I think the current protocols for Windows drivers are not trustable thus I'll keep not installing them. Some bullet proof protocol should be created, otherwise it is impossible to get any trust. And this protocol must NOT depend on M$ nor on Qubes (wonderful) team. Something else.
>
>
>
> El dom., 14 abr. 2024 12:15, Gerhard Weck <> gerhard...@gmail.com> > escribió:
>

>> I think, here a word of caution is appropriate regarding the use of Microsoft-signed keys. As a >> current CISA report <https://www.cisa.gov/sites/default/files/2024-04/CSRB_Review_of_the_Summer_2023_MEO_Intrusion_Final_508c.pdf>>> shows, there have been severe security breaches in the Microsft environment, and they are still continuing, as Microsoft does not seem able to kick the Russian Midnight Blizzard hackers out of its network. For this reason, one should not, security-wise, put too much (any?) trust into Mircosoft signatures of crypto keys, while, concerning QWT, their use is clearly convenient, as it removes the need for running Windows qubes with test-signing enabled.

>>
>> But apart from that, I would trust the security management of Qubes itself much more, where the philosophy is based on not trusting the infrastructure, checking the code by the developers themselves and possibly by the community, and not relying on the security of some external agent.
>>
>> Andrew David Wong schrieb am Sonntag, 14. April 2024 um 10:14:20 UTC+2:
>>
>>> On 4/13/24 8:56 AM, jmake2 via qubes-devel wrote:
>>> > [...]
>>> >
>>> > So, am I getting it right that QWT is not deprecated? I was afraid for a moment.
>>>
>>> As stated in the QSB, the developers are still working on QWT, so it is not deprecated.
>>>
>>> > As it was discussed previously, the QWT package can be build from secure and available sources and put to R4.2+ repos with different signatures, including secure self-signed but not Microsoft-approved key. Requirement to allow self-signed drivers is not perfect, but still a way better solution than current situation, to my understanding.
>>> >
>>> > [...]
>>>
>>> I believe this is the relevant issue:
>>>
>>> https://github.com/QubesOS/qubes-issues/issues/9019
>>>

> I think the current protocols for Windows drivers are not trustable thus I'll keep not installing them. Some bullet proof protocol should be created, otherwise it is impossible to get any trust. And this protocol must NOT depend on M$ nor on Qubes (wonderful) team. Something else.

There is no issue with the protocol, security of the Qubes OS (dom0 and other qubes), sources of the Xen drivers or something else, please read QSB. The problem is only with the packaging system of Xen, it could have been compromised and the resulting binaries are less reliable. Otherwise there is no need to avoid QWT as a project, it still provides user great experience of both file copying and clipboard bidirectional access.
Back to the topic, is it possible or preferable to postpone R4.1 EOL until https://github.com/QubesOS/qubes-issues/issues/9019 is completed (in one way or another), and the QWT be returned to the system?

[Steve Coleman]

> I got used to use safer ways to copy files from my Windows to other qubes

If there are alternative ways to perform any of these lost operations without the drivers then this should be documented to at least partially alleviate the problem. There must be a way even if that requires using a developer key to self sign a driver.  I'm not familiar with that process at all. 

Off hand the only thing I can think of would be passing a r/w volume using qvm-start to allow passing files in or out. Is there a file system type that will not get corrupted?  That does not fix cut-and-paste functionality but there could be a workaround to auto type into the vm using the current keyboard interface. Using a network app as a proxy? E.g ssh port forwarding? Just thinking off the top of my head here. 

I have been needing to rebuild my Win10 VM because it refuses to update, but I also need to upgrade to 4.2.1 and it seems like my own use case for Windows on Qubes is a showstopper without at least some level of this functionality. I could be loosing the use of several software licenses if I can't find a workaround solution when migrating to 4.2.1

To view this discussion on the web visit https://groups.google.com/d/msgid/qubes-devel/CA%2Bi0rxtG5nd0-ghoB_N3Q%3DTf_XrHaCm_Q8PbhMUfomAfNZ1cPg%40mail.gmail.com.

[Rob Townley]

Ten days ago, it came out that a nation state bullied the single lone developer of `xz`.   There were some Windows Tools for running  Windows on QubesOS.  They worked.   Windows ran fast even though debug mode had to be enabled which could make it less secure.  After Feb 2022, I was very hesitant because the primary developers were in Russia.  Even if these Russian primary developers were trustworthy, we have no idea how much bathroom window pressure is put on them and their family members.   Not sure if their code is audited by Polish Qubes-OS developers? 

The following says the relevant server was decommissioned and the drivers rebuilt from trusted sources. 

"Xen Security Notice 1 v1 - winpvdrvbuild.xenproject.org potentially compromised"

https://lists.xenproject.org/archives/html/xen-announce/2023-07/msg00000.html

ACTIONS TAKEN
=============

The possibly compromised system has been decommissioned.

We have removed all previous binaries from:

https://xenbits.xen.org/pvdrivers/win/

A new set of drivers based on the current master branch
(9.0-unstable) and built on a trusted environment have been uploaded
on the same folder

p.s.  Loved that CISA.gov article.  Ever since the Office of Personnel Management, aka OPM hack, so many other hacks,  and again with the SolarWinds supply chain hack, both the entire US government and Microsoft keying material  should have been recreated from scratch on trusted systems. 

To view this discussion on the web visit https://groups.google.com/d/msgid/qubes-devel/CAJ5FDngrkH8FPUNfuebu0C6iA_6Zm_BC83Wj9OdkBANG%2BeU9Lg%40mail.gmail.com.