QSB #44: Multiple Xen vulnerabilities (XSA-275, XSA-280)
https://www.qubes-os.org/news/2018/11/20/qsb-44/
We have just published Qubes Security Bulletin (QSB) #44: Multiple Xen
vulnerabilities (XSA-275, XSA-280). The text of this QSB is reproduced
below. This QSB and its accompanying signatures will always be available
in the Qubes Security Pack (qubes-secpack).
View QSB #44 in the qubes-secpack:
https://github.com/QubesOS/qubes-secpack/blob/master/QSBs/qsb-044-2018.txt
Learn about the qubes-secpack, including how to obtain, verify, and read
it:
https://www.qubes-os.org/security/pack/
View all past QSBs:
https://www.qubes-os.org/security/bulletins/
View XSA-275 and XSA-280 in the XSA Tracker:
https://www.qubes-os.org/security/xsa/#275
https://www.qubes-os.org/security/xsa/#280
---===[ Qubes Security Bulletin #44 ]===---
2018-11-20
Multiple Xen vulnerabilities (XSA-275, XSA-280)
Summary
========
On 2018-11-20, the Xen Security Team published multiple Xen Security
Advisories (XSAs):
XSA-275 [1] "insufficient TLB flushing / improper large page mappings
with AMD IOMMUs":
| In order to be certain that no undue access to memory is possible
| anymore after IOMMU mappings of this memory have been removed,
| Translation Lookaside Buffers (TLBs) need to be flushed after most
| changes to such mappings. Xen bypassed certain IOMMU flushes on AMD
| x86 hardware.
|
| Furthermore logic exists Xen to re-combine small page mappings
| into larger ones. Such re-combination could have occured in cases
| when it was not really safe/correct to do so.
|
| A malicious or buggy guest may be able to escalate its privileges, may
| cause a Denial of Service (DoS) affecting the entire host, or may be
| able to access data it is not supposed to access (information leak).
XSA-275 affects only AMD CPUs using IOMMU on both Qubes OS 3.2 and Qubes
OS 4.0. XSA-275 does not affect Intel CPUs on any Qubes OS version.
XSA-280 [2] "Fix for XSA-240 conflicts with shadow paging":
| The fix for XSA-240 introduced a new field into the control structure
| associated with each page of RAM. This field was added to a union,
| another member of which is used when Xen uses shadow paging for the
| guest. During migration, or with the L1TF (XSA-273) mitigation for
| PV guests in effect, the two uses conflict.
|
| A malicious or buggy x86 PV guest may cause Xen to crash, resulting in
| a DoS (Denial of Service) affecting the entire host. Privilege
| escalation as well as information leaks cannot be ruled out.
XSA-280 affects only Qubes OS 3.2. XSA-280 does not affect Qubes OS 4.0,
since the shadow paging feature is disabled at build time for 4.0.
Patching
=========
The specific packages that resolve the problems discussed in this
bulletin are as follows:
For Qubes OS 3.2:
- Xen packages, version 4.6.6-45
For Qubes OS 4.0:
- Xen packages, version 4.8.4-7
The packages are to be installed in dom0 via the Qubes VM Manager or via
the qubes-dom0-update command as follows:
For updates from the stable repository (not immediately available):
$ sudo qubes-dom0-update
For updates from the security-testing repository:
$ sudo qubes-dom0-update --enablerepo=qubes-dom0-security-testing
A system restart will be required afterwards.
These packages will migrate from the security-testing repository to the
current (stable) repository over the next two weeks after being tested
by the community.
If you use Anti Evil Maid, you will need to reseal your secret
passphrase to new PCR values, as PCR18+19 will change due to the new
Xen binaries.
Credits
========
See the original Xen Security Advisory.
References
===========
[1] https://xenbits.xen.org/xsa/advisory-275.html
[2] https://xenbits.xen.org/xsa/advisory-280.html
--
The Qubes Security Team
https://www.qubes-os.org/security/
https://www.qubes-os.org/news/2018/11/20/qsb-44/
We have just published Qubes Security Bulletin (QSB) #44: Multiple Xen
vulnerabilities (XSA-275, XSA-280). The text of this QSB is reproduced
below. This QSB and its accompanying signatures will always be available
in the Qubes Security Pack (qubes-secpack).
View QSB #44 in the qubes-secpack:
https://github.com/QubesOS/qubes-secpack/blob/master/QSBs/qsb-044-2018.txt
Learn about the qubes-secpack, including how to obtain, verify, and read
it:
https://www.qubes-os.org/security/pack/
View all past QSBs:
https://www.qubes-os.org/security/bulletins/
View XSA-275 and XSA-280 in the XSA Tracker:
https://www.qubes-os.org/security/xsa/#275
https://www.qubes-os.org/security/xsa/#280
---===[ Qubes Security Bulletin #44 ]===---
2018-11-20
Multiple Xen vulnerabilities (XSA-275, XSA-280)
Summary
========
On 2018-11-20, the Xen Security Team published multiple Xen Security
Advisories (XSAs):
XSA-275 [1] "insufficient TLB flushing / improper large page mappings
with AMD IOMMUs":
| In order to be certain that no undue access to memory is possible
| anymore after IOMMU mappings of this memory have been removed,
| Translation Lookaside Buffers (TLBs) need to be flushed after most
| changes to such mappings. Xen bypassed certain IOMMU flushes on AMD
| x86 hardware.
|
| Furthermore logic exists Xen to re-combine small page mappings
| into larger ones. Such re-combination could have occured in cases
| when it was not really safe/correct to do so.
|
| A malicious or buggy guest may be able to escalate its privileges, may
| cause a Denial of Service (DoS) affecting the entire host, or may be
| able to access data it is not supposed to access (information leak).
XSA-275 affects only AMD CPUs using IOMMU on both Qubes OS 3.2 and Qubes
OS 4.0. XSA-275 does not affect Intel CPUs on any Qubes OS version.
XSA-280 [2] "Fix for XSA-240 conflicts with shadow paging":
| The fix for XSA-240 introduced a new field into the control structure
| associated with each page of RAM. This field was added to a union,
| another member of which is used when Xen uses shadow paging for the
| guest. During migration, or with the L1TF (XSA-273) mitigation for
| PV guests in effect, the two uses conflict.
|
| A malicious or buggy x86 PV guest may cause Xen to crash, resulting in
| a DoS (Denial of Service) affecting the entire host. Privilege
| escalation as well as information leaks cannot be ruled out.
XSA-280 affects only Qubes OS 3.2. XSA-280 does not affect Qubes OS 4.0,
since the shadow paging feature is disabled at build time for 4.0.
Patching
=========
The specific packages that resolve the problems discussed in this
bulletin are as follows:
For Qubes OS 3.2:
- Xen packages, version 4.6.6-45
For Qubes OS 4.0:
- Xen packages, version 4.8.4-7
The packages are to be installed in dom0 via the Qubes VM Manager or via
the qubes-dom0-update command as follows:
For updates from the stable repository (not immediately available):
$ sudo qubes-dom0-update
For updates from the security-testing repository:
$ sudo qubes-dom0-update --enablerepo=qubes-dom0-security-testing
A system restart will be required afterwards.
These packages will migrate from the security-testing repository to the
current (stable) repository over the next two weeks after being tested
by the community.
If you use Anti Evil Maid, you will need to reseal your secret
passphrase to new PCR values, as PCR18+19 will change due to the new
Xen binaries.
Credits
========
See the original Xen Security Advisory.
References
===========
[1] https://xenbits.xen.org/xsa/advisory-275.html
[2] https://xenbits.xen.org/xsa/advisory-280.html
--
The Qubes Security Team
https://www.qubes-os.org/security/
Fedora 27 has reached EOL
https://www.qubes-os.org/news/2018/11/30/fedora-27-eol/
The Fedora Project announced today that Fedora 27 has reached EOL
(end-of-life (https://fedoraproject.org/wiki/Fedora_Release_Life_Cycle#Maintenance_Schedule)). We strongly recommend that all Qubes users upgrade
their Fedora 27 TemplateVMs and StandaloneVMs to Fedora 28 immediately.
We provide step-by-step upgrade instructions for upgrading from Fedora
27 to 28 (https://www.qubes-os.org/doc/template/fedora/upgrade-27-to-28/). For a complete list of TemplateVM versions supported for your
specific version of Qubes, see Supported TemplateVM Versions (https://www.qubes-os.org/doc/supported-versions/#templatevms).
We also provide a fresh Fedora 28 TemplateVM package through the
official Qubes repositories, which you can install in dom0 by following
the standard installation instructions (https://www.qubes-os.org/doc/templates/fedora/#installing).
After upgrading your TemplateVMs, please remember to set all qubes that
were using the old template to use the new one. The instructions to do
this can be found in the upgrade instructions for Fedora 27 to 28 (https://www.qubes-os.org/doc/template/fedora/upgrade-27-to-28/).
Please note that no user action is required regarding the OS version in
dom0. For details, please see our Note on dom0 and EOL (https://www.qubes-os.org/doc/supported-versions/#note-on-dom0-and-eol).
https://www.qubes-os.org/news/2018/11/30/fedora-27-eol/
The Fedora Project announced today that Fedora 27 has reached EOL
(end-of-life (https://fedoraproject.org/wiki/Fedora_Release_Life_Cycle#Maintenance_Schedule)). We strongly recommend that all Qubes users upgrade
their Fedora 27 TemplateVMs and StandaloneVMs to Fedora 28 immediately.
We provide step-by-step upgrade instructions for upgrading from Fedora
27 to 28 (https://www.qubes-os.org/doc/template/fedora/upgrade-27-to-28/). For a complete list of TemplateVM versions supported for your
specific version of Qubes, see Supported TemplateVM Versions (https://www.qubes-os.org/doc/supported-versions/#templatevms).
We also provide a fresh Fedora 28 TemplateVM package through the
official Qubes repositories, which you can install in dom0 by following
the standard installation instructions (https://www.qubes-os.org/doc/templates/fedora/#installing).
After upgrading your TemplateVMs, please remember to set all qubes that
were using the old template to use the new one. The instructions to do
this can be found in the upgrade instructions for Fedora 27 to 28 (https://www.qubes-os.org/doc/template/fedora/upgrade-27-to-28/).
Please note that no user action is required regarding the OS version in
dom0. For details, please see our Note on dom0 and EOL (https://www.qubes-os.org/doc/supported-versions/#note-on-dom0-and-eol).
QSB #45: Insecure default Salt configuration
https://www.qubes-os.org/news/2018/12/03/qsb-45/
We have just published Qubes Security Bulletin (QSB) #45: Insecure
default Salt configuration. The text of this QSB is reproduced below.
This QSB and its accompanying signatures will always be available in
the Qubes Security Pack (qubes-secpack).
View QSB #45 in the qubes-secpack:
https://github.com/QubesOS/qubes-secpack/blob/master/QSBs/qsb-045-2018.txt
Learn about the qubes-secpack, including how to obtain, verify, and read
it:
https://www.qubes-os.org/security/pack/
View all past QSBs:
https://www.qubes-os.org/security/bulletins/
---===[ Qubes Security Bulletin #45 ]===---
2018-12-03
Insecure default Salt configuration
Summary
========
In Qubes OS, one use of Salt (aka SaltStack) is to configure software
installed in domUs (including TemplateVMs and AppVMs). [1] To protect
dom0 from potentially compromised domUs, all complex processing is done
in a DisposableVM. [2] Each target domU being configured gets a separate
DisposableVM, which is given power to execute arbitrary commands
(through the qubes.VMShell qrexec service) in that target domU.
In the default configuration, each DisposableVM generated for this
purpose is based on the same default DVM Template that is used for all
other default DisposableVM actions (including the default "Disposable:
Firefox" menu entry). This DVM Template has a red label and has
networking enabled, which might suggest that it is not
security-critical. However, if this default DVM Template were
compromised (for example, by a web browser plugin the user had installed
there [3]), then the next time Salt were used, it could also compromise
all target domUs it were configuring.
Although it is possible to use an alternative DVM Template for Salt, the
option to do so has not been exposed through any command-line or
graphical user interface.
Vulnerable systems
==================
To exploit this vulnerability, two conditions must be met:
1. The user must actively use Salt to configure software inside a domU.
This does not happen by default; user intervention is required. Only
domUs configured by Salt are affected.
2. The user must compromise the default DVM Template. (For example, the
user might customize the DVM Template by installing an untrusted
program in it, not realizing the security implications of doing so.)
The issue affects only Qubes OS 4.0. In Qubes 3.2, Salt processing
occurs in a temporary AppVM based on the default TemplateVM.
Resolution
==========
To fix this problem, we are implementing two changes:
1. Adding the "management_dispvm" VM property, which specifies the DVM
Template that should be used for management, such as Salt
configuration. TemplateBasedVMs inherit this property from their
parent TemplateVMs. If the value is not set explicitly, the default
is taken from the global "management_dispvm" property. The
VM-specific property is set with the qvm-prefs command, while the
global property is set with the qubes-prefs command.
2. Creating the "default-mgmt-dvm" DVM Template, which is hidden from
the menu (to avoid accidental use), has networking disabled, and has
a black label (the same as TemplateVMs). This VM is set as the global
"management_dispvm".
Patching
=========
The specific packages that resolve the problems discussed in this
bulletin are as follows:
For Qubes OS 4.0:
- qubes-core-dom0 version 4.0.36
- qubes-mgmt-salt-dom0-virtual-machines version 4.0.15
- qubes-mgmt-salt-admin-tools version 4.0.12
For Qubes OS 3.2:
- No packages necessary, since 3.2 is not affected.
(See above for details.)
The packages are to be installed in dom0 via the Qubes VM Manager or via
the qubes-dom0-update command as follows:
For updates from the stable repository (not immediately available):
$ sudo qubes-dom0-update
https://www.qubes-os.org/news/2018/12/03/qsb-45/
We have just published Qubes Security Bulletin (QSB) #45: Insecure
default Salt configuration. The text of this QSB is reproduced below.
This QSB and its accompanying signatures will always be available in
the Qubes Security Pack (qubes-secpack).
View QSB #45 in the qubes-secpack:
https://github.com/QubesOS/qubes-secpack/blob/master/QSBs/qsb-045-2018.txt
Learn about the qubes-secpack, including how to obtain, verify, and read
it:
https://www.qubes-os.org/security/pack/
View all past QSBs:
https://www.qubes-os.org/security/bulletins/
---===[ Qubes Security Bulletin #45 ]===---
2018-12-03
Insecure default Salt configuration
Summary
========
In Qubes OS, one use of Salt (aka SaltStack) is to configure software
installed in domUs (including TemplateVMs and AppVMs). [1] To protect
dom0 from potentially compromised domUs, all complex processing is done
in a DisposableVM. [2] Each target domU being configured gets a separate
DisposableVM, which is given power to execute arbitrary commands
(through the qubes.VMShell qrexec service) in that target domU.
In the default configuration, each DisposableVM generated for this
purpose is based on the same default DVM Template that is used for all
other default DisposableVM actions (including the default "Disposable:
Firefox" menu entry). This DVM Template has a red label and has
networking enabled, which might suggest that it is not
security-critical. However, if this default DVM Template were
compromised (for example, by a web browser plugin the user had installed
there [3]), then the next time Salt were used, it could also compromise
all target domUs it were configuring.
Although it is possible to use an alternative DVM Template for Salt, the
option to do so has not been exposed through any command-line or
graphical user interface.
Vulnerable systems
==================
To exploit this vulnerability, two conditions must be met:
1. The user must actively use Salt to configure software inside a domU.
This does not happen by default; user intervention is required. Only
domUs configured by Salt are affected.
2. The user must compromise the default DVM Template. (For example, the
user might customize the DVM Template by installing an untrusted
program in it, not realizing the security implications of doing so.)
The issue affects only Qubes OS 4.0. In Qubes 3.2, Salt processing
occurs in a temporary AppVM based on the default TemplateVM.
Resolution
==========
To fix this problem, we are implementing two changes:
1. Adding the "management_dispvm" VM property, which specifies the DVM
Template that should be used for management, such as Salt
configuration. TemplateBasedVMs inherit this property from their
parent TemplateVMs. If the value is not set explicitly, the default
is taken from the global "management_dispvm" property. The
VM-specific property is set with the qvm-prefs command, while the
global property is set with the qubes-prefs command.
2. Creating the "default-mgmt-dvm" DVM Template, which is hidden from
the menu (to avoid accidental use), has networking disabled, and has
a black label (the same as TemplateVMs). This VM is set as the global
"management_dispvm".
Patching
=========
The specific packages that resolve the problems discussed in this
bulletin are as follows:
For Qubes OS 4.0:
- qubes-core-dom0 version 4.0.36
- qubes-mgmt-salt-dom0-virtual-machines version 4.0.15
- qubes-mgmt-salt-admin-tools version 4.0.12
For Qubes OS 3.2:
- No packages necessary, since 3.2 is not affected.
(See above for details.)
The packages are to be installed in dom0 via the Qubes VM Manager or via
the qubes-dom0-update command as follows:
For updates from the stable repository (not immediately available):
$ sudo qubes-dom0-update
For updates from the security-testing repository:
$ sudo qubes-dom0-update --enablerepo=qubes-dom0-security-testing
These packages will migrate from the security-testing repository to the
current (stable) repository over the next two weeks after being tested
by the community.
Credits
========
The issue was reported by Demi M. Obenour
References
===========
[1] https://www.qubes-os.org/doc/salt/#configuring-a-vms-system-from-dom0
[2] https://github.com/QubesOS/qubes-issues/issues/1541#issuecomment-187482786
[3] https://www.qubes-os.org/doc/dispvm-customization/
--
The Qubes Security Team
https://www.qubes-os.org/security/
$ sudo qubes-dom0-update --enablerepo=qubes-dom0-security-testing
These packages will migrate from the security-testing repository to the
current (stable) repository over the next two weeks after being tested
by the community.
Credits
========
The issue was reported by Demi M. Obenour
References
===========
[1] https://www.qubes-os.org/doc/salt/#configuring-a-vms-system-from-dom0
[2] https://github.com/QubesOS/qubes-issues/issues/1541#issuecomment-187482786
[3] https://www.qubes-os.org/doc/dispvm-customization/
--
The Qubes Security Team
https://www.qubes-os.org/security/
Xen Project 4.11.1 and 4.8.5 are available
https://blog.xenproject.org/2018/12/13/xen-project-4-11-1-and-4-8-5-are-available/
I am pleased to announce the release of Xen 4.11.1 and 4.8.5. Xen Project Maintenance releases are released in line with our Maintenance Release Policy. We recommend that all users of the 4.11 and 4.8 stable series update to the latest point release. These releases are available from their git repositories xenbits.xen.org/gitweb/?p=xen.git;a=shortlog;h=refs/heads/stable-4.11 (tag RELEASE-4.11.1) xenbits.xen.org/gitweb/?p=xen.git;a=shortlog;h=refs/heads/stable-4.8 […]
https://blog.xenproject.org/2018/12/13/xen-project-4-11-1-and-4-8-5-are-available/
I am pleased to announce the release of Xen 4.11.1 and 4.8.5. Xen Project Maintenance releases are released in line with our Maintenance Release Policy. We recommend that all users of the 4.11 and 4.8 stable series update to the latest point release. These releases are available from their git repositories xenbits.xen.org/gitweb/?p=xen.git;a=shortlog;h=refs/heads/stable-4.11 (tag RELEASE-4.11.1) xenbits.xen.org/gitweb/?p=xen.git;a=shortlog;h=refs/heads/stable-4.8 […]
Qubes OS 4.0.1-rc2 has been released!
https://www.qubes-os.org/news/2018/12/18/qubes-401-rc2/
We’re pleased to announce the second release candidate for Qubes 4.0.1!
Features:
Fixes for bugs discovered in 4.0.1-rc1
All 4.0 dom0 updates to date
Fedora 29 TemplateVM
Debian 9 TemplateVM
Whonix 14 Gateway and Workstation TemplateVMs
Linux kernel 4.14
Qubes 4.0.1-rc2 is available on the Downloads (https://www.qubes-os.org/downloads/) page.
What is a point release?
A point release does not designate a separate, new version of Qubes OS.
Rather, it designates its respective major or minor release (in this
case, 4.0) inclusive of all updates up to a certain point. Installing
Qubes 4.0 and fully updating it results in the same system as installing
Qubes 4.0.1.
What should I do?
If you’re currently using an up-to-date Qubes 4.0 installation, then
your system is already equivalent to a Qubes 4.0.1 installation. No
action is needed.
Regardless of your current OS, if you wish to install (or reinstall)
Qubes 4.0 for any reason, then the 4.0.1 ISO will make this more
convenient and secure, since it bundles all Qubes 4.0 updates to date.
It will be especially helpful for users whose hardware is too new to be
compatible with the original Qubes 4.0 installer.
Release planning
Since the most severe bugs related to Fedora 29 have been addressed, we
expect that this will be the final release candidate for 4.0.1. As
usual, you can help by reporting any bugs you
encounter (https://www.qubes-os.org/doc/reporting-bugs/). If no major problems are discovered in this
release candidate, 4.0.1 should follow in approximately three weeks.
https://www.qubes-os.org/news/2018/12/18/qubes-401-rc2/
We’re pleased to announce the second release candidate for Qubes 4.0.1!
Features:
Fixes for bugs discovered in 4.0.1-rc1
All 4.0 dom0 updates to date
Fedora 29 TemplateVM
Debian 9 TemplateVM
Whonix 14 Gateway and Workstation TemplateVMs
Linux kernel 4.14
Qubes 4.0.1-rc2 is available on the Downloads (https://www.qubes-os.org/downloads/) page.
What is a point release?
A point release does not designate a separate, new version of Qubes OS.
Rather, it designates its respective major or minor release (in this
case, 4.0) inclusive of all updates up to a certain point. Installing
Qubes 4.0 and fully updating it results in the same system as installing
Qubes 4.0.1.
What should I do?
If you’re currently using an up-to-date Qubes 4.0 installation, then
your system is already equivalent to a Qubes 4.0.1 installation. No
action is needed.
Regardless of your current OS, if you wish to install (or reinstall)
Qubes 4.0 for any reason, then the 4.0.1 ISO will make this more
convenient and secure, since it bundles all Qubes 4.0 updates to date.
It will be especially helpful for users whose hardware is too new to be
compatible with the original Qubes 4.0 installer.
Release planning
Since the most severe bugs related to Fedora 29 have been addressed, we
expect that this will be the final release candidate for 4.0.1. As
usual, you can help by reporting any bugs you
encounter (https://www.qubes-os.org/doc/reporting-bugs/). If no major problems are discovered in this
release candidate, 4.0.1 should follow in approximately three weeks.
Introduction to Qubes this Saturday at the 35th CCC in Leipzig
https://www.qubes-os.org/news/2018/12/27/introduction-to-qubes-at-35c3/
Wojtek Porczyk (https://www.qubes-os.org/team/#wojtek-porczyk) will be hosting an “Introduction to Qubes OS” (https://events.ccc.de/congress/2018/wiki/index.php/Session:Introduction_to_Qubes_OS) workshop this
Saturday (2018-12-29) at the 35th Chaos Communication Congress (35C3) (https://events.ccc.de/congress/2018/wiki/index.php/Main_Page) in
Leipzig, Germany. We’ll start with the absolute basics and build from there; no
prior knowledge needed! All are welcome!
https://www.qubes-os.org/news/2018/12/27/introduction-to-qubes-at-35c3/
Wojtek Porczyk (https://www.qubes-os.org/team/#wojtek-porczyk) will be hosting an “Introduction to Qubes OS” (https://events.ccc.de/congress/2018/wiki/index.php/Session:Introduction_to_Qubes_OS) workshop this
Saturday (2018-12-29) at the 35th Chaos Communication Congress (35C3) (https://events.ccc.de/congress/2018/wiki/index.php/Main_Page) in
Leipzig, Germany. We’ll start with the absolute basics and build from there; no
prior knowledge needed! All are welcome!
Fedora 29 TemplateVM available for Qubes 4.0
https://www.qubes-os.org/news/2019/01/07/fedora-29-template-available/
A new Fedora 29 TemplateVM is now available for Qubes 4.0. We
previously announced that Fedora 27 reached EOL (https://www.qubes-os.org/news/2018/11/30/fedora-27-eol/) and encouraged users
to upgrade to Fedora 28. Fedora 28 is still supported by the Fedora
Project, so users may now choose either Fedora 28 or 29 (or both)
depending on their needs and preferences. Instructions are available
for upgrading from Fedora 28 to 29 (https://www.qubes-os.org/doc/template/fedora/upgrade-28-to-29/). We also provide fresh Fedora 29
TemplateVM packages through the official Qubes repositories, which you
can get with the following commands (in dom0).
Standard Fedora 29 TemplateVM:
$ sudo qubes-dom0-update qubes-template-fedora-29
Minimal (https://www.qubes-os.org/doc/templates/fedora-minimal/) Fedora 29 TemplateVM:
$ sudo qubes-dom0-update qubes-template-fedora-29-minimal
After upgrading to a Fedora 29 TemplateVM, please remember to set all
qubes that were using the old template to use the new one. This can be
done in dom0 either with the Qubes Template Manager (https://www.qubes-os.org/doc/templates/#how-to-switch-templates-40) or with the
qvm-prefs command-line tool.
https://www.qubes-os.org/news/2019/01/07/fedora-29-template-available/
A new Fedora 29 TemplateVM is now available for Qubes 4.0. We
previously announced that Fedora 27 reached EOL (https://www.qubes-os.org/news/2018/11/30/fedora-27-eol/) and encouraged users
to upgrade to Fedora 28. Fedora 28 is still supported by the Fedora
Project, so users may now choose either Fedora 28 or 29 (or both)
depending on their needs and preferences. Instructions are available
for upgrading from Fedora 28 to 29 (https://www.qubes-os.org/doc/template/fedora/upgrade-28-to-29/). We also provide fresh Fedora 29
TemplateVM packages through the official Qubes repositories, which you
can get with the following commands (in dom0).
Standard Fedora 29 TemplateVM:
$ sudo qubes-dom0-update qubes-template-fedora-29
Minimal (https://www.qubes-os.org/doc/templates/fedora-minimal/) Fedora 29 TemplateVM:
$ sudo qubes-dom0-update qubes-template-fedora-29-minimal
After upgrading to a Fedora 29 TemplateVM, please remember to set all
qubes that were using the old template to use the new one. This can be
done in dom0 either with the Qubes Template Manager (https://www.qubes-os.org/doc/templates/#how-to-switch-templates-40) or with the
qvm-prefs command-line tool.
Comment on Celebrating 15 Years of the Xen Project and Our Future by Lars Kurth
https://blog.xenproject.org/2018/10/23/celebrating-15-years-of-the-xen-project-and-our-future/#comment-572
Hi,
when you talk about Xen, do you mean Xen Project or XenServer. Some of what you say seems to be related to XenServer, which is a commercial product built on top of Xen
Lars
https://blog.xenproject.org/2018/10/23/celebrating-15-years-of-the-xen-project-and-our-future/#comment-572
Hi,
when you talk about Xen, do you mean Xen Project or XenServer. Some of what you say seems to be related to XenServer, which is a commercial product built on top of Xen
Lars
Qubes Canary #18
https://www.qubes-os.org/news/2019/01/08/canary-18/
Dear Qubes Community,
We have published Qubes Canary #18. The text of this canary is
reproduced below. This canary and its accompanying signatures will
always be available in the Qubes Security Pack (qubes-secpack).
View Qubes Canary #18 in the qubes-secpack:
https://github.com/QubesOS/qubes-secpack/blob/master/canaries/canary-018-2019.txt
Learn about the qubes-secpack, including how to obtain, verify, and read
it:
https://www.qubes-os.org/security/pack/
View all past canaries:
https://www.qubes-os.org/security/canaries/
---===[ Qubes Canary #18 ]===---
Statements
-----------
The Qubes core developers who have digitally signed this file [1]
state the following:
1. The date of issue of this canary is January 8, 2019.
2. There have been 45 Qubes Security Bulletins published so far.
3. The Qubes Master Signing Key fingerprint is:
427F 11FD 0FAA 4B08 0123 F01C DDFA 1A3E 3687 9494
4. No warrants have ever been served to us with regard to the Qubes OS
Project (e.g. to hand out the private signing keys or to introduce
backdoors).
5. We plan to publish the next of these canary statements in the first
two weeks of April 2019. Special note should be taken if no new canary
is published by that time or if the list of statements changes without
plausible explanation.
Special announcements
----------------------
Simon Gaiser (aka HW42) joined the Qubes Security Team. More details:
https://www.qubes-os.org/news/2018/11/05/qubes-security-team-update/
Disclaimers and notes
----------------------
We would like to remind you that Qubes OS has been designed under the
assumption that all relevant infrastructure is permanently
compromised. This means that we assume NO trust in any of the servers
or services which host or provide any Qubes-related data, in
particular, software updates, source code repositories, and Qubes ISO
downloads.
This canary scheme is not infallible. Although signing the declaration
makes it very difficult for a third party to produce arbitrary
declarations, it does not prevent them from using force or other
means, like blackmail or compromising the signers' laptops, to coerce
us to produce false declarations.
The news feeds quoted below (Proof of freshness) serves to demonstrate
that this canary could not have been created prior to the date stated.
It shows that a series of canaries was not created in advance.
This declaration is merely a best effort and is provided without any
guarantee or warranty. It is not legally binding in any way to
anybody. None of the signers should be ever held legally responsible
for any of the statements made here.
Proof of freshness
-------------------
$ date -R -u
Tue, 08 Jan 2019 03:18:51 +0000
$ feedstail -1 -n5 -f '{noscript}' -u https://www.spiegel.de/international/index.rss
Avi Loeb on the Mysterious Interstellar Body 'Oumuamua: 'Thinking About Distant Civilizations Isn't Speculative'
The Year of Populism: Europe's Right Wing Takes Aim at the EU
Women in Startups: 'The Most Successful Teams Are Diverse Teams'
Fergus Falls: A Fantastic Town
The Claas Relotius Affair: DER SPIEGEL's Reaction to U.S. Ambassador's Criticism
$ feedstail -1 -n5 -f '{noscript}' -u https://rss.nytimes.com/services/xml/rss/nyt/World.xml
Philippines Dispatch: Where 518 Inmates Sleep in Space for 170, and Gangs Hold It Together
Migrants’ Despair Is Growing at U.S. Border. So Are Smugglers’ Profits.
Poland Cracks Down on Escape Rooms After Diversion Turns Deadly
Kim Jong-un, North Korea’s Leader, Visits China
Fleeing Saudi Woman, Facing Deportation, Is Allowed to Remain in Thailand
$ feedstail -1 -n5 -f '{noscript}' -u https://feeds.bbci.co.uk/news/world/rss.xml
North Korea's Kim Jong-un visits China's Xi Jinping
Ex-Nissan boss says he is wrongly accused
Guatemala expels UN-backed anti-corruption commission
Yellow vests: France to crack down on unsanctioned protests
https://www.qubes-os.org/news/2019/01/08/canary-18/
Dear Qubes Community,
We have published Qubes Canary #18. The text of this canary is
reproduced below. This canary and its accompanying signatures will
always be available in the Qubes Security Pack (qubes-secpack).
View Qubes Canary #18 in the qubes-secpack:
https://github.com/QubesOS/qubes-secpack/blob/master/canaries/canary-018-2019.txt
Learn about the qubes-secpack, including how to obtain, verify, and read
it:
https://www.qubes-os.org/security/pack/
View all past canaries:
https://www.qubes-os.org/security/canaries/
---===[ Qubes Canary #18 ]===---
Statements
-----------
The Qubes core developers who have digitally signed this file [1]
state the following:
1. The date of issue of this canary is January 8, 2019.
2. There have been 45 Qubes Security Bulletins published so far.
3. The Qubes Master Signing Key fingerprint is:
427F 11FD 0FAA 4B08 0123 F01C DDFA 1A3E 3687 9494
4. No warrants have ever been served to us with regard to the Qubes OS
Project (e.g. to hand out the private signing keys or to introduce
backdoors).
5. We plan to publish the next of these canary statements in the first
two weeks of April 2019. Special note should be taken if no new canary
is published by that time or if the list of statements changes without
plausible explanation.
Special announcements
----------------------
Simon Gaiser (aka HW42) joined the Qubes Security Team. More details:
https://www.qubes-os.org/news/2018/11/05/qubes-security-team-update/
Disclaimers and notes
----------------------
We would like to remind you that Qubes OS has been designed under the
assumption that all relevant infrastructure is permanently
compromised. This means that we assume NO trust in any of the servers
or services which host or provide any Qubes-related data, in
particular, software updates, source code repositories, and Qubes ISO
downloads.
This canary scheme is not infallible. Although signing the declaration
makes it very difficult for a third party to produce arbitrary
declarations, it does not prevent them from using force or other
means, like blackmail or compromising the signers' laptops, to coerce
us to produce false declarations.
The news feeds quoted below (Proof of freshness) serves to demonstrate
that this canary could not have been created prior to the date stated.
It shows that a series of canaries was not created in advance.
This declaration is merely a best effort and is provided without any
guarantee or warranty. It is not legally binding in any way to
anybody. None of the signers should be ever held legally responsible
for any of the statements made here.
Proof of freshness
-------------------
$ date -R -u
Tue, 08 Jan 2019 03:18:51 +0000
$ feedstail -1 -n5 -f '{noscript}' -u https://www.spiegel.de/international/index.rss
Avi Loeb on the Mysterious Interstellar Body 'Oumuamua: 'Thinking About Distant Civilizations Isn't Speculative'
The Year of Populism: Europe's Right Wing Takes Aim at the EU
Women in Startups: 'The Most Successful Teams Are Diverse Teams'
Fergus Falls: A Fantastic Town
The Claas Relotius Affair: DER SPIEGEL's Reaction to U.S. Ambassador's Criticism
$ feedstail -1 -n5 -f '{noscript}' -u https://rss.nytimes.com/services/xml/rss/nyt/World.xml
Philippines Dispatch: Where 518 Inmates Sleep in Space for 170, and Gangs Hold It Together
Migrants’ Despair Is Growing at U.S. Border. So Are Smugglers’ Profits.
Poland Cracks Down on Escape Rooms After Diversion Turns Deadly
Kim Jong-un, North Korea’s Leader, Visits China
Fleeing Saudi Woman, Facing Deportation, Is Allowed to Remain in Thailand
$ feedstail -1 -n5 -f '{noscript}' -u https://feeds.bbci.co.uk/news/world/rss.xml
North Korea's Kim Jong-un visits China's Xi Jinping
Ex-Nissan boss says he is wrongly accused
Guatemala expels UN-backed anti-corruption commission
Yellow vests: France to crack down on unsanctioned protests
Kevin Spacey in court to face charges of groping teenager
$ feedstail -1 -n5 -f '{noscript}' -u http://feeds.reuters.com/reuters/worldnews
North Korea leader visits China after warning of alternate path to U.S. talks
Myanmar's civilian, military leaders meet, vow to "crush" Rakhine rebels
Guatemala to shut down U.N. anti-corruption body early
Trump, Trudeau agree to press China on detained Canadians: Ottawa
White House says Trump position unchanged as Syria withdrawal plans slow
$ curl -s 'https://blockchain.info/blocks/?format=json' |\
python3 -c 'import sys, json; print(json.load(sys.stdin)['\''blocks'\''][10]['\''hash'\''])'
000000000000000000073048d01300bb6ca9102dd0641f065cb42d5659412915
Footnotes
----------
[1] This file should be signed in two ways: (1) via detached PGP
signatures by each of the signers, distributed together with this
canary in the qubes-secpack.git repo, and (2) via digital signatures
on the corresponding qubes-secpack.git repo tags. [2]
[2] Don't just trust the contents of this file blindly! Verify the
digital signatures!
$ feedstail -1 -n5 -f '{noscript}' -u http://feeds.reuters.com/reuters/worldnews
North Korea leader visits China after warning of alternate path to U.S. talks
Myanmar's civilian, military leaders meet, vow to "crush" Rakhine rebels
Guatemala to shut down U.N. anti-corruption body early
Trump, Trudeau agree to press China on detained Canadians: Ottawa
White House says Trump position unchanged as Syria withdrawal plans slow
$ curl -s 'https://blockchain.info/blocks/?format=json' |\
python3 -c 'import sys, json; print(json.load(sys.stdin)['\''blocks'\''][10]['\''hash'\''])'
000000000000000000073048d01300bb6ca9102dd0641f065cb42d5659412915
Footnotes
----------
[1] This file should be signed in two ways: (1) via detached PGP
signatures by each of the signers, distributed together with this
canary in the qubes-secpack.git repo, and (2) via digital signatures
on the corresponding qubes-secpack.git repo tags. [2]
[2] Don't just trust the contents of this file blindly! Verify the
digital signatures!
Qubes OS 4.0.1 has been released!
https://www.qubes-os.org/news/2019/01/09/qubes-401/
We’re pleased to announce the release of Qubes 4.0.1! This is the first
stable point release of Qubes 4.0. It includes many updates over the
initial 4.0 release, in particular:
All 4.0 dom0 updates to date, including a lot of bug fixes and
improvements for GUI tools
Fedora 29 TemplateVM
Debian 9 TemplateVM
Whonix 14 Gateway and Workstation TemplateVMs
Linux kernel 4.14
Qubes 4.0.1 is available on the Downloads (https://www.qubes-os.org/downloads/) page.
What is a point release?
A point release does not designate a separate, new version of Qubes OS.
Rather, it designates its respective major or minor release (in this
case, 4.0) inclusive of all updates up to a certain point. Installing
Qubes 4.0 and fully updating it results in the same system as installing
Qubes 4.0.1.
What should I do?
If you’re currently using an up-to-date Qubes 4.0 installation
(including updated Fedora 29, Debian 9, and Whonix 14 templates), then
your system is already equivalent to a Qubes 4.0.1 installation. No
action is needed.
Similarly, if you’re currently using a Qubes 4.0.1 release candidate
(4.0.1-rc1 or 4.0.1-rc2), and you’ve followed the standard procedure for
keeping it up-to-date, then your system is equivalent to a 4.0.1 stable
installation, and no additional action is needed.
If you’re currently using Qubes 4.0 but don’t have these new templates
installed yet, we recommend that you follow the appropriate
documentation to do so:
Fedora 29 (https://www.qubes-os.org/doc/template/fedora/upgrade-28-to-29/)
Debian 9 (https://www.qubes-os.org/doc/template/debian/upgrade-8-to-9/)
Whonix 14 (https://www.whonix.org/wiki/Upgrading_Whonix_13_to_Whonix_14)
Regardless of your current OS, if you wish to install (or reinstall)
Qubes 4.0 for any reason, then the 4.0.1 ISO will make this more
convenient and secure, since it bundles all Qubes 4.0 updates to date.
It will be especially helpful for users whose hardware is too new to be
compatible with the original Qubes 4.0 installer.
https://www.qubes-os.org/news/2019/01/09/qubes-401/
We’re pleased to announce the release of Qubes 4.0.1! This is the first
stable point release of Qubes 4.0. It includes many updates over the
initial 4.0 release, in particular:
All 4.0 dom0 updates to date, including a lot of bug fixes and
improvements for GUI tools
Fedora 29 TemplateVM
Debian 9 TemplateVM
Whonix 14 Gateway and Workstation TemplateVMs
Linux kernel 4.14
Qubes 4.0.1 is available on the Downloads (https://www.qubes-os.org/downloads/) page.
What is a point release?
A point release does not designate a separate, new version of Qubes OS.
Rather, it designates its respective major or minor release (in this
case, 4.0) inclusive of all updates up to a certain point. Installing
Qubes 4.0 and fully updating it results in the same system as installing
Qubes 4.0.1.
What should I do?
If you’re currently using an up-to-date Qubes 4.0 installation
(including updated Fedora 29, Debian 9, and Whonix 14 templates), then
your system is already equivalent to a Qubes 4.0.1 installation. No
action is needed.
Similarly, if you’re currently using a Qubes 4.0.1 release candidate
(4.0.1-rc1 or 4.0.1-rc2), and you’ve followed the standard procedure for
keeping it up-to-date, then your system is equivalent to a 4.0.1 stable
installation, and no additional action is needed.
If you’re currently using Qubes 4.0 but don’t have these new templates
installed yet, we recommend that you follow the appropriate
documentation to do so:
Fedora 29 (https://www.qubes-os.org/doc/template/fedora/upgrade-28-to-29/)
Debian 9 (https://www.qubes-os.org/doc/template/debian/upgrade-8-to-9/)
Whonix 14 (https://www.whonix.org/wiki/Upgrading_Whonix_13_to_Whonix_14)
Regardless of your current OS, if you wish to install (or reinstall)
Qubes 4.0 for any reason, then the 4.0.1 ISO will make this more
convenient and secure, since it bundles all Qubes 4.0 updates to date.
It will be especially helpful for users whose hardware is too new to be
compatible with the original Qubes 4.0 installer.
XSA-289 does not affect the security of Qubes OS
https://www.qubes-os.org/news/2019/01/21/xsa-289-qubes-not-affected/
The Xen Project has published Xen Security Advisory 289 (XSA-289).
This XSA does not affect the security of Qubes OS, and no user
action is necessary.
XSA-289 is unusual in that it does not disclose any new
vulnerabilities. Rather, it is only for the purpose of providing
information about previously-disclosed vulnerabilities. These
vulnerabilities were all patched in Qubes OS as part of QSB #43 (https://www.qubes-os.org/news/2018/09/02/qsb-43/),
which we published on 2018-09-02. Therefore, XSA-289 does not affect
the security of updated Qubes OS installations.
This XSA has been added to the XSA Tracker (https://www.qubes-os.org/security/xsa/):
https://www.qubes-os.org/security/xsa/#289
https://www.qubes-os.org/news/2019/01/21/xsa-289-qubes-not-affected/
The Xen Project has published Xen Security Advisory 289 (XSA-289).
This XSA does not affect the security of Qubes OS, and no user
action is necessary.
XSA-289 is unusual in that it does not disclose any new
vulnerabilities. Rather, it is only for the purpose of providing
information about previously-disclosed vulnerabilities. These
vulnerabilities were all patched in Qubes OS as part of QSB #43 (https://www.qubes-os.org/news/2018/09/02/qsb-43/),
which we published on 2018-09-02. Therefore, XSA-289 does not affect
the security of updated Qubes OS installations.
This XSA has been added to the XSA Tracker (https://www.qubes-os.org/security/xsa/):
https://www.qubes-os.org/security/xsa/#289
QSB #46: APT update mechanism vulnerability
https://www.qubes-os.org/news/2019/01/23/qsb-46/
We have just published Qubes Security Bulletin (QSB) #46: APT update mechanism
vulnerability. The text of this QSB is reproduced below.
This QSB and its accompanying signatures will always be available in
the Qubes Security Pack (qubes-secpack).
View QSB #46 in the qubes-secpack:
https://github.com/QubesOS/qubes-secpack/blob/master/QSBs/qsb-046-2019.txt
Learn about the qubes-secpack, including how to obtain, verify, and read
it:
https://www.qubes-os.org/security/pack/
View all past QSBs:
https://www.qubes-os.org/security/bulletins/
---===[ Qubes Security Bulletin #46 ]===---
2019-01-23
APT update mechanism vulnerability
Summary
========
The Debian Security Team has announced a security vulnerability
(DSA-4371-1) in the Advanced Package Tool (APT). The vulnerability lies
in the way APT performs HTTP redirect handling when downloading
packages. Exploitation of this vulnerability could lead to privilege
escalation [1] inside an APT-based VM, such as a Debian or Whonix VM.
This bug does _not_ allow escape from any VM or enable any attacks on
other parts of the Qubes system. In particular, this bug does _not_
affect dom0, the Xen hypervisor, or any non-APT-based VMs. Nevertheless,
we have decided to release this bulletin, because if a TemplateVM is
affected, then every VM based on that template is affected.
Denoscription
============
As described in [1]:
| Max Justicz discovered a vulnerability in APT, the high level package
| manager. The code handling HTTP redirects in the HTTP transport
| method doesn't properly sanitize fields transmitted over the wire.
| This vulnerability could be used by an attacker located as a
| man-in-the-middle between APT and a mirror to inject malicious content
| in the HTTP connection. This content could then be recognized as a
| valid package by APT and used later for code execution with root
| privileges on the target machine.
Impact
=======
Users who use Debian or Whonix VMs are affected. Users who use only
Fedora VMs are not affected. Although we do not provide any other
official or community APT-based templates, any other APT-based VMs that
users have installed on their own should also be assumed to be affected.
Discussion
===========
Normally, we do not release Qubes Security Bulletins (QSBs) to address
vulnerabilities that only affect VMs internally without affecting the
rest of the Qubes system, i.e. vulnerabilities that do not undermine the
Qubes security model.
For example, we do not release QSBs to address bugs in Firefox or Linux
kernel USB stacks, because Qubes OS was designed under the primary
assumption that in a typical desktop OS there will be countless such
bugs and that humankind will never be able to patch all of them promptly
(at least not as quickly as developers introduce new bugs). This is, in
fact, the very reason we designed Qubes OS as an implementation of the
security-by-compartmentalization approach.
The APT update bug discussed today is, however, somewhat special.
While it is indeed a bug that only affects VMs internally, it could
allow an attacker to compromise TemplateVMs, which are used as a basis
for creating other VMs, such as AppVMs and ServiceVMs. If a TemplateVM
is compromised, then all the VMs based on that TemplateVM will be
compromised. Since AppVMs operate directly on user data, and since
ServiceVMs can be critical to user privacy (especially in the case of
Whonix and VPN ProxyVMs), this is a serious matter.
In Qubes OS, we take special precautions to make TemplateVMs difficult
to compromise. For example, we block all network connections to and from
templates, with one exception: We allow templates to connect to the
so-called "Update Proxy" (which runs in the NetVM). This allows the
TemplateVM to retrieve updates while protecting users from accidentally
https://www.qubes-os.org/news/2019/01/23/qsb-46/
We have just published Qubes Security Bulletin (QSB) #46: APT update mechanism
vulnerability. The text of this QSB is reproduced below.
This QSB and its accompanying signatures will always be available in
the Qubes Security Pack (qubes-secpack).
View QSB #46 in the qubes-secpack:
https://github.com/QubesOS/qubes-secpack/blob/master/QSBs/qsb-046-2019.txt
Learn about the qubes-secpack, including how to obtain, verify, and read
it:
https://www.qubes-os.org/security/pack/
View all past QSBs:
https://www.qubes-os.org/security/bulletins/
---===[ Qubes Security Bulletin #46 ]===---
2019-01-23
APT update mechanism vulnerability
Summary
========
The Debian Security Team has announced a security vulnerability
(DSA-4371-1) in the Advanced Package Tool (APT). The vulnerability lies
in the way APT performs HTTP redirect handling when downloading
packages. Exploitation of this vulnerability could lead to privilege
escalation [1] inside an APT-based VM, such as a Debian or Whonix VM.
This bug does _not_ allow escape from any VM or enable any attacks on
other parts of the Qubes system. In particular, this bug does _not_
affect dom0, the Xen hypervisor, or any non-APT-based VMs. Nevertheless,
we have decided to release this bulletin, because if a TemplateVM is
affected, then every VM based on that template is affected.
Denoscription
============
As described in [1]:
| Max Justicz discovered a vulnerability in APT, the high level package
| manager. The code handling HTTP redirects in the HTTP transport
| method doesn't properly sanitize fields transmitted over the wire.
| This vulnerability could be used by an attacker located as a
| man-in-the-middle between APT and a mirror to inject malicious content
| in the HTTP connection. This content could then be recognized as a
| valid package by APT and used later for code execution with root
| privileges on the target machine.
Impact
=======
Users who use Debian or Whonix VMs are affected. Users who use only
Fedora VMs are not affected. Although we do not provide any other
official or community APT-based templates, any other APT-based VMs that
users have installed on their own should also be assumed to be affected.
Discussion
===========
Normally, we do not release Qubes Security Bulletins (QSBs) to address
vulnerabilities that only affect VMs internally without affecting the
rest of the Qubes system, i.e. vulnerabilities that do not undermine the
Qubes security model.
For example, we do not release QSBs to address bugs in Firefox or Linux
kernel USB stacks, because Qubes OS was designed under the primary
assumption that in a typical desktop OS there will be countless such
bugs and that humankind will never be able to patch all of them promptly
(at least not as quickly as developers introduce new bugs). This is, in
fact, the very reason we designed Qubes OS as an implementation of the
security-by-compartmentalization approach.
The APT update bug discussed today is, however, somewhat special.
While it is indeed a bug that only affects VMs internally, it could
allow an attacker to compromise TemplateVMs, which are used as a basis
for creating other VMs, such as AppVMs and ServiceVMs. If a TemplateVM
is compromised, then all the VMs based on that TemplateVM will be
compromised. Since AppVMs operate directly on user data, and since
ServiceVMs can be critical to user privacy (especially in the case of
Whonix and VPN ProxyVMs), this is a serious matter.
In Qubes OS, we take special precautions to make TemplateVMs difficult
to compromise. For example, we block all network connections to and from
templates, with one exception: We allow templates to connect to the
so-called "Update Proxy" (which runs in the NetVM). This allows the
TemplateVM to retrieve updates while protecting users from accidentally
using TemplateVMs to perform risky activities, such as browsing the web.
Since the bug under discussion has the potential to subvert this very
protection mechanism, we've decided to issue this QSB.
We would like to point out, however, that Qubes OS does a good job of
mitigating this kind of a vulnerability. Instead of having to reinstall
the whole operating system from scratch, Qubes users may need only to
reinstall the affected template(s).
If users are concerned that potential attackers may have compromised not
only the root filesystem of the template, but also attempted to infect
user files in AppVM filesystems (e.g. ~/.bashrc or a Web browser profile
directory), Qubes allows for mounting each of the suspected AppVM
private images into a different, trusted VM, based on a trusted
template, for "offline" analysis and cleanup, allowing users to preserve
their data.
Patching
=========
If you are a Qubes user, you should remove all APT-based (including
Debian and Whonix) TemplateVMs and StandaloneVMs, then install fresh
ones. You can do this by performing the following steps on each such
TemplateVM:
1. Note any customizations you have made to the target TemplateVM.
2. Temporarily change all VMs based on the target TemplateVM to a
different template, or remove them.
Temporarily switching to a different template can be a good idea if
you have user data in these VMs that you want to keep. On the other
hand, if you suspect that these VMs are compromised, you may want to
remove them instead. You can remove them in Qube(s) Manager by
right-clicking on the VM and clicking "Remove VM" or "Delete qube,"
or you can use this command in dom0:
$ qvm-remove
3. Uninstall the target TemplateVM from dom0:
$ sudo dnf remove
This requires specifying the template package name (not the
TemplateVM's name). A list of affected template package names is
provided below. For example, to uninstall the whonix-gw-14 template:
$ sudo dnf remove qubes-template-whonix-gw-14
4. Reinstall the target TemplateVM in dom0:
$ sudo qubes-dom0-update --enablerepo= \
This requires specifying the template package name (not the
TemplateVM's name). A list of new (fixed) template package names is
provided below. For example, to install the whonix-gw-14
template:
$ sudo qubes-dom0-update --enablerepo=qubes-templates-community \
qubes-template-whonix-gw-14
Then verify the right version was installed:
$ rpm -q qubes-template-whonix-gw-14
qubes-template-whonix-gw-14-4.0.1-201901231238.noarch
In accordance with our standard policy, new (fixed) template packages
will first reside in the testing repositories for approximately two
weeks before migrating to the stable repositories. In order to
install a templates package from its testing repository, you must
enable that repository. For example, to install the whonix-gw-14
template from its testing repository:
$ sudo qubes-dom0-update \
--enablerepo=qubes-templates-community-testing \
qubes-template-whonix-gw-14
5. If you temporarily changed all VMs based on the target TemplateVM to
a different template in step 2, change them back to the fresh
TemplateVM now. If you instead removed all VMs based on the old
TemplateVM, you can recreate your desired VMs from the fresh
TemplateVM now.
6. If you noted any template customizations in step 1, clone the target
TemplateVM, then reapply your customizations to the clone.
Old (vulnerable) and new (fixed) Qubes TemplateVM packages are listed
for each supported Qubes OS version in the tables below:
Qubes 4.0:
+------------------------------------------------------------------------------+
| Old (Vulnerable) | New (Fixed) |
| --------------------------- | ---------------------------------------------- |
| qubes-template-debian-8 | qubes-template-debian-8-4.0.1-201901231241 |
Since the bug under discussion has the potential to subvert this very
protection mechanism, we've decided to issue this QSB.
We would like to point out, however, that Qubes OS does a good job of
mitigating this kind of a vulnerability. Instead of having to reinstall
the whole operating system from scratch, Qubes users may need only to
reinstall the affected template(s).
If users are concerned that potential attackers may have compromised not
only the root filesystem of the template, but also attempted to infect
user files in AppVM filesystems (e.g. ~/.bashrc or a Web browser profile
directory), Qubes allows for mounting each of the suspected AppVM
private images into a different, trusted VM, based on a trusted
template, for "offline" analysis and cleanup, allowing users to preserve
their data.
Patching
=========
If you are a Qubes user, you should remove all APT-based (including
Debian and Whonix) TemplateVMs and StandaloneVMs, then install fresh
ones. You can do this by performing the following steps on each such
TemplateVM:
1. Note any customizations you have made to the target TemplateVM.
2. Temporarily change all VMs based on the target TemplateVM to a
different template, or remove them.
Temporarily switching to a different template can be a good idea if
you have user data in these VMs that you want to keep. On the other
hand, if you suspect that these VMs are compromised, you may want to
remove them instead. You can remove them in Qube(s) Manager by
right-clicking on the VM and clicking "Remove VM" or "Delete qube,"
or you can use this command in dom0:
$ qvm-remove
3. Uninstall the target TemplateVM from dom0:
$ sudo dnf remove
This requires specifying the template package name (not the
TemplateVM's name). A list of affected template package names is
provided below. For example, to uninstall the whonix-gw-14 template:
$ sudo dnf remove qubes-template-whonix-gw-14
4. Reinstall the target TemplateVM in dom0:
$ sudo qubes-dom0-update --enablerepo= \
This requires specifying the template package name (not the
TemplateVM's name). A list of new (fixed) template package names is
provided below. For example, to install the whonix-gw-14
template:
$ sudo qubes-dom0-update --enablerepo=qubes-templates-community \
qubes-template-whonix-gw-14
Then verify the right version was installed:
$ rpm -q qubes-template-whonix-gw-14
qubes-template-whonix-gw-14-4.0.1-201901231238.noarch
In accordance with our standard policy, new (fixed) template packages
will first reside in the testing repositories for approximately two
weeks before migrating to the stable repositories. In order to
install a templates package from its testing repository, you must
enable that repository. For example, to install the whonix-gw-14
template from its testing repository:
$ sudo qubes-dom0-update \
--enablerepo=qubes-templates-community-testing \
qubes-template-whonix-gw-14
5. If you temporarily changed all VMs based on the target TemplateVM to
a different template in step 2, change them back to the fresh
TemplateVM now. If you instead removed all VMs based on the old
TemplateVM, you can recreate your desired VMs from the fresh
TemplateVM now.
6. If you noted any template customizations in step 1, clone the target
TemplateVM, then reapply your customizations to the clone.
Old (vulnerable) and new (fixed) Qubes TemplateVM packages are listed
for each supported Qubes OS version in the tables below:
Qubes 4.0:
+------------------------------------------------------------------------------+
| Old (Vulnerable) | New (Fixed) |
| --------------------------- | ---------------------------------------------- |
| qubes-template-debian-8 | qubes-template-debian-8-4.0.1-201901231241 |
| qubes-template-debian-9 | qubes-template-debian-9-4.0.1-201901230644 |
| qubes-template-whonix-gw-14 | qubes-template-whonix-gw-14-4.0.1-201901231238 |
| qubes-template-whonix-ws-14 | qubes-template-whonix-ws-14-4.0.1-201901231238 |
+------------------------------------------------------------------------------+
Qubes 3.2:
+--------------------------------------------------------------------------+
| Old (Vulnerable) | New (Fixed) |
| --------------------------- | ------------------------------------------ |
| qubes-template-debian-8 | qubes-template-debian-8-4.0.1-201901230645 |
| qubes-template-debian-9 | qubes-template-debian-9-4.0.1-201901230645 |
| qubes-template-whonix-gw-14 | not supported |
| qubes-template-whonix-ws-14 | not supported |
+--------------------------------------------------------------------------+
Alternative patching for non-critical TemplateVMs
==================================================
Users who do not rely on APT-based VMs for any critical tasks may
instead opt just to install fixed APT packages. This is _not_ secure if
the template has already been compromised. If you are not willing to
take the risk that the template may already be compromised, you should
instead follow the instructions in the previous section to completely
remove the template, then install a fresh one.
As the bug is present in the update mechanism itself, special care
should be taken while performing the update, as described in [1]. We
include those steps in GUI tools used to update, so updating the GUI
tools and performing the template update with either of them will also
apply the fix in a safe way, as long as the TemplateVM is not already
compromised.
Important: Listed below are the minimum package versions that will
perform APT updates safely. However, after installing these packages,
you must also update all APT-based TemplateVMs normally through the
Qubes VM Manager. Installing the packages listed below is not enough.
Qubes 4.0:
- qubes-desktop-linux-manager 4.0.14 (updates widget)
- qubes-manager 4.0.27 (Qube Manager)
Qubes 3.2:
- qubes-manager 3.2.14 (Qubes VM Manager)
The packages are to be installed in dom0 via the Qubes VM Manager or via
the qubes-dom0-update command as follows:
For updates from the stable repository (not immediately available):
$ sudo qubes-dom0-update
For updates from the security-testing repository:
$ sudo qubes-dom0-update --enablerepo=qubes-dom0-security-testing
Now you can safely update your APT-based TemplateVMs through the Qubes
VM Manger.
Credits
========
This vulnerability was discovered by Max Justicz and reported to the
Debian Security Team.
References
===========
[1] https://www.debian.org/security/2019/dsa-4371
--
The Qubes Security Team
https://www.qubes-os.org/security/
| qubes-template-whonix-gw-14 | qubes-template-whonix-gw-14-4.0.1-201901231238 |
| qubes-template-whonix-ws-14 | qubes-template-whonix-ws-14-4.0.1-201901231238 |
+------------------------------------------------------------------------------+
Qubes 3.2:
+--------------------------------------------------------------------------+
| Old (Vulnerable) | New (Fixed) |
| --------------------------- | ------------------------------------------ |
| qubes-template-debian-8 | qubes-template-debian-8-4.0.1-201901230645 |
| qubes-template-debian-9 | qubes-template-debian-9-4.0.1-201901230645 |
| qubes-template-whonix-gw-14 | not supported |
| qubes-template-whonix-ws-14 | not supported |
+--------------------------------------------------------------------------+
Alternative patching for non-critical TemplateVMs
==================================================
Users who do not rely on APT-based VMs for any critical tasks may
instead opt just to install fixed APT packages. This is _not_ secure if
the template has already been compromised. If you are not willing to
take the risk that the template may already be compromised, you should
instead follow the instructions in the previous section to completely
remove the template, then install a fresh one.
As the bug is present in the update mechanism itself, special care
should be taken while performing the update, as described in [1]. We
include those steps in GUI tools used to update, so updating the GUI
tools and performing the template update with either of them will also
apply the fix in a safe way, as long as the TemplateVM is not already
compromised.
Important: Listed below are the minimum package versions that will
perform APT updates safely. However, after installing these packages,
you must also update all APT-based TemplateVMs normally through the
Qubes VM Manager. Installing the packages listed below is not enough.
Qubes 4.0:
- qubes-desktop-linux-manager 4.0.14 (updates widget)
- qubes-manager 4.0.27 (Qube Manager)
Qubes 3.2:
- qubes-manager 3.2.14 (Qubes VM Manager)
The packages are to be installed in dom0 via the Qubes VM Manager or via
the qubes-dom0-update command as follows:
For updates from the stable repository (not immediately available):
$ sudo qubes-dom0-update
For updates from the security-testing repository:
$ sudo qubes-dom0-update --enablerepo=qubes-dom0-security-testing
Now you can safely update your APT-based TemplateVMs through the Qubes
VM Manger.
Credits
========
This vulnerability was discovered by Max Justicz and reported to the
Debian Security Team.
References
===========
[1] https://www.debian.org/security/2019/dsa-4371
--
The Qubes Security Team
https://www.qubes-os.org/security/
There will be a Qubes talk / demo at Join me at Stockholm Cybersecurity Meetup February http://meetu.ps/e/G0XM5/wxTFj/a in Stockholm end of next month
Meetup
Stockholm Cybersecurity Meetup
This meetup is for all cybersecurity enthusiasts in Stockholm.If cybersecurity is your work, studies or just a passion (or all of the above), join our meetups to exchange ideas, build networks, organi
Xen Project Developer and Design Summit: Registration Open Now
https://blog.xenproject.org/2019/01/30/xen-project-developer-and-design-summit-registration-open-now/
Starting today, registration officially opens for The Xen Project Developer & Design Summit. This year’s Summit, taking place from July 9 through 11 in Chicago, will bring together the Xen Project community of developers and power users to share ideas, latest developments, and experiences, as well as offer opportunities to plan and collaborate on all […]
https://blog.xenproject.org/2019/01/30/xen-project-developer-and-design-summit-registration-open-now/
Starting today, registration officially opens for The Xen Project Developer & Design Summit. This year’s Summit, taking place from July 9 through 11 in Chicago, will bring together the Xen Project community of developers and power users to share ideas, latest developments, and experiences, as well as offer opportunities to plan and collaborate on all […]