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 […]
Xen Project Celebrates Unikraft Unikernel Project’s One Year Anniversary
https://blog.xenproject.org/2019/01/31/xen-project-celebrates-unikraft-unikernel-projects-one-year-anniversary/
It has been one year since the Xen Project introduced Unikraft as an incubator project. In that time, the team has made great strides in simplifying the process of building unikernels through a unified and customizable code base. Unikraft is an incubation project under the Xen Project, hosted by the Linux Foundation, focused on easing […]
https://blog.xenproject.org/2019/01/31/xen-project-celebrates-unikraft-unikernel-projects-one-year-anniversary/
It has been one year since the Xen Project introduced Unikraft as an incubator project. In that time, the team has made great strides in simplifying the process of building unikernels through a unified and customizable code base. Unikraft is an incubation project under the Xen Project, hosted by the Linux Foundation, focused on easing […]
Comment on Xen Project Celebrates Unikraft Unikernel Project’s One Year Anniversary by Xen Project Celebrates Unikraft Unikernel Project's One Year Anniversary | Linux.com | Top Tech Stories
https://blog.xenproject.org/2019/01/31/xen-project-celebrates-unikraft-unikernel-projects-one-year-anniversary/#comment-574
[…] This article in the beginning seemed at Xen Project. […]
https://blog.xenproject.org/2019/01/31/xen-project-celebrates-unikraft-unikernel-projects-one-year-anniversary/#comment-574
[…] This article in the beginning seemed at Xen Project. […]
Comment on Xen Project Celebrates Unikraft Unikernel Project’s One Year Anniversary by Xen Project Celebrates Unikraft Unikernel Project’s One Year Anniversary |
https://blog.xenproject.org/2019/01/31/xen-project-celebrates-unikraft-unikernel-projects-one-year-anniversary/#comment-575
[…] This article originally appeared at Xen Project. […]
https://blog.xenproject.org/2019/01/31/xen-project-celebrates-unikraft-unikernel-projects-one-year-anniversary/#comment-575
[…] This article originally appeared at Xen Project. […]
QSB #47: Insecure default DisposableVM networking configuration
https://www.qubes-os.org/news/2019/02/19/qsb-47/
We have just published Qubes Security Bulletin (QSB) #47: Insecure default
DisposableVM networking 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 #47 in the qubes-secpack:
https://github.com/QubesOS/qubes-secpack/blob/master/QSBs/qsb-047-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 #47 ]===---
2019-02-19
Insecure default DisposableVM networking configuration
Summary
========
In Qubes OS, one can attempt to limit the network access of a qube by
either completely disconnecting it from any NetVM or by setting its
firewall rules to disallow access. A malicious qube can circumvent these
limits by launching a DisposableVM [1], which, in the default
configuration, would have unrestricted network access.
Moreover, even when a non-default DisposableVM is configured to have no
network access (or limited access), other DisposableVMs started from
_that_ DisposableVM can have full network access (unless explicitly
configured otherwise).
While limiting network access in this manner should not be considered to
be an effective leak-prevention mechanism [1], we still consider this
type of potentially ineffective network isolation to be a problem.
Details
========
In Qubes 4.0, each DisposableVM is based on a DVM Template [2] with the
`template_for_dispvm` property set to "True". The DisposableVM inherits
all of its settings from the DVM Template, including the `netvm`
property and firewall rules. Neither the network settings nor any other
settings of the calling qube are considered. This design is intentional,
as it allows much more flexibility over the previous model. For example,
one could create different DVM Templates for different purposes, such as
opening links (internet access), viewing documents (offline), printing
(drivers installed), etc. Each DVM Template has appropriate network
settings for its purpose.
The important part of this design is the `default_dispvm` qube property.
The value of this property is the DVM Template that will be used when
starting new DisposableVMs from that qube. In the default configuration,
Qubes OS has one default DVM Template, which has unrestricted network
access. The default DVM Template is the default value of the global
`default_dispvm` property, which is accessible via "Global settings" in
the Qube Manager or via the `qubes-prefs` tool. This global property
serves as the default value for the `default_dispvm` property for every
qube. If the user creates a non-default DVM Template with limited
network access, the user must also set the `default_dispvm` value
(either globally or on a per-qube basis) in order for any new
DisposableVM to be based on this non-default DVM Template.
In the Whonix configuration shipped with Qubes, this issue is avoided by
creating a separate DVM Template that uses the Whonix Gateway
(`sys-whonix`) as its NetVM. The `default_dispvm` property of this DVM
Template is set to itself. This DVM Template is the value of the
`default_dispvm` property for every Whonix Workstation.
This problem is partially mitigated when restoring a backup from Qubes
3.2. For each qube that has the `dispvm_netvm` property set to "none", a
separate DVM Template named `disp-no-netvm` is created. This DVM
Template has no direct network access. However, this DVM Template itself
has the default value for its own `default_dispvm` property, so
DisposableVMs started from it or from DisposableVMs based on it would
have full network access.
Vulnerable systems
==================
https://www.qubes-os.org/news/2019/02/19/qsb-47/
We have just published Qubes Security Bulletin (QSB) #47: Insecure default
DisposableVM networking 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 #47 in the qubes-secpack:
https://github.com/QubesOS/qubes-secpack/blob/master/QSBs/qsb-047-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 #47 ]===---
2019-02-19
Insecure default DisposableVM networking configuration
Summary
========
In Qubes OS, one can attempt to limit the network access of a qube by
either completely disconnecting it from any NetVM or by setting its
firewall rules to disallow access. A malicious qube can circumvent these
limits by launching a DisposableVM [1], which, in the default
configuration, would have unrestricted network access.
Moreover, even when a non-default DisposableVM is configured to have no
network access (or limited access), other DisposableVMs started from
_that_ DisposableVM can have full network access (unless explicitly
configured otherwise).
While limiting network access in this manner should not be considered to
be an effective leak-prevention mechanism [1], we still consider this
type of potentially ineffective network isolation to be a problem.
Details
========
In Qubes 4.0, each DisposableVM is based on a DVM Template [2] with the
`template_for_dispvm` property set to "True". The DisposableVM inherits
all of its settings from the DVM Template, including the `netvm`
property and firewall rules. Neither the network settings nor any other
settings of the calling qube are considered. This design is intentional,
as it allows much more flexibility over the previous model. For example,
one could create different DVM Templates for different purposes, such as
opening links (internet access), viewing documents (offline), printing
(drivers installed), etc. Each DVM Template has appropriate network
settings for its purpose.
The important part of this design is the `default_dispvm` qube property.
The value of this property is the DVM Template that will be used when
starting new DisposableVMs from that qube. In the default configuration,
Qubes OS has one default DVM Template, which has unrestricted network
access. The default DVM Template is the default value of the global
`default_dispvm` property, which is accessible via "Global settings" in
the Qube Manager or via the `qubes-prefs` tool. This global property
serves as the default value for the `default_dispvm` property for every
qube. If the user creates a non-default DVM Template with limited
network access, the user must also set the `default_dispvm` value
(either globally or on a per-qube basis) in order for any new
DisposableVM to be based on this non-default DVM Template.
In the Whonix configuration shipped with Qubes, this issue is avoided by
creating a separate DVM Template that uses the Whonix Gateway
(`sys-whonix`) as its NetVM. The `default_dispvm` property of this DVM
Template is set to itself. This DVM Template is the value of the
`default_dispvm` property for every Whonix Workstation.
This problem is partially mitigated when restoring a backup from Qubes
3.2. For each qube that has the `dispvm_netvm` property set to "none", a
separate DVM Template named `disp-no-netvm` is created. This DVM
Template has no direct network access. However, this DVM Template itself
has the default value for its own `default_dispvm` property, so
DisposableVMs started from it or from DisposableVMs based on it would
have full network access.
Vulnerable systems
==================
This issue affects only Qubes 4.0. In Qubes 3.2, the network settings of
DisposableVM are inherited from the calling qube's settings (more
specifically, from its `dispvm_netvm` property, which defaults to the
`netvm` property's value).
The Whonix configuration shipped with Qubes 4.0 is not affected by this
issue. If you have installed Whonix using a method other than the
recommended `qubesctl` command [4], you should review the settings of
your Whonix qubes. Specifically:
- whonix-ws-14-dvm should have `netvm` set to sys-whonix
- whonix-ws-14-dvm should have `default_dispvm` set to whonix-ws-14-dvm
- anon-whonix and any other Whonix Workstations should have
`default_dispvm` set to whonix-ws-14-dvm
See the Whonix documentation [4] for details.
Systems in which the default DVM Template is disconnected from the
network (by settings its `netvm` property to "none") are not affected by
this issue.
Resolution
==========
To mitigate this problem, we are implementing two changes:
1. When a DisposableVM is started, automatically set its
`default_dispvm` to the DVM Template on which it is based. This means
that, when a DisposableVM is started from another DisposableVM, they
will both be based on the same DVM Template. Hence, they will have
all the same settings, including the same network settings. This
change will not affect DVM Templates for which user has manually
modified the `default_dispvm` property.
2. Add a warning message in the Qube Settings GUI when the NetVM of a
qube in the "Basic" tab is set to a different value than the NetVM of
the default DVM Template set in the "Advanced" tab.
Note that these changes concern only NetVM settings, not firewall
settings. If you want your DisposableVMs to have the same firewall
settings as the calling qube, you must adjust the firewall settings of
appropriate DVM Template yourself.
In the next version of Qubes, we will ship two DVM Templates by default:
one with network access and one without. This was already previously
discussed in issue #1121 [5].
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.39
- qubes-manager version 4.0.28
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 Vít 'v6ak' Šesták.
References
===========
[1] https://www.qubes-os.org/doc/disposablevm/
[2] https://www.qubes-os.org/doc/data-leaks/
[3] https://www.qubes-os.org/doc/glossary/#dvm-template
[4] https://www.whonix.org/wiki/Qubes/Install
[5] https://github.com/QubesOS/qubes-issues/issues/1121
--
The Qubes Security Team
https://www.qubes-os.org/security/
DisposableVM are inherited from the calling qube's settings (more
specifically, from its `dispvm_netvm` property, which defaults to the
`netvm` property's value).
The Whonix configuration shipped with Qubes 4.0 is not affected by this
issue. If you have installed Whonix using a method other than the
recommended `qubesctl` command [4], you should review the settings of
your Whonix qubes. Specifically:
- whonix-ws-14-dvm should have `netvm` set to sys-whonix
- whonix-ws-14-dvm should have `default_dispvm` set to whonix-ws-14-dvm
- anon-whonix and any other Whonix Workstations should have
`default_dispvm` set to whonix-ws-14-dvm
See the Whonix documentation [4] for details.
Systems in which the default DVM Template is disconnected from the
network (by settings its `netvm` property to "none") are not affected by
this issue.
Resolution
==========
To mitigate this problem, we are implementing two changes:
1. When a DisposableVM is started, automatically set its
`default_dispvm` to the DVM Template on which it is based. This means
that, when a DisposableVM is started from another DisposableVM, they
will both be based on the same DVM Template. Hence, they will have
all the same settings, including the same network settings. This
change will not affect DVM Templates for which user has manually
modified the `default_dispvm` property.
2. Add a warning message in the Qube Settings GUI when the NetVM of a
qube in the "Basic" tab is set to a different value than the NetVM of
the default DVM Template set in the "Advanced" tab.
Note that these changes concern only NetVM settings, not firewall
settings. If you want your DisposableVMs to have the same firewall
settings as the calling qube, you must adjust the firewall settings of
appropriate DVM Template yourself.
In the next version of Qubes, we will ship two DVM Templates by default:
one with network access and one without. This was already previously
discussed in issue #1121 [5].
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.39
- qubes-manager version 4.0.28
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 Vít 'v6ak' Šesták.
References
===========
[1] https://www.qubes-os.org/doc/disposablevm/
[2] https://www.qubes-os.org/doc/data-leaks/
[3] https://www.qubes-os.org/doc/glossary/#dvm-template
[4] https://www.whonix.org/wiki/Qubes/Install
[5] https://github.com/QubesOS/qubes-issues/issues/1121
--
The Qubes Security Team
https://www.qubes-os.org/security/
Qubes OS 3.2 approaching EOL on 2019-03-28
https://www.qubes-os.org/news/2019/02/20/qubes-3-2-approaching-eol/
Qubes OS releases are normally supported (https://www.qubes-os.org/doc/supported-versions/) for six months after each
subsequent major or minor release (https://www.qubes-os.org/doc/version-scheme/). However, in light of the more
demanding system requirements (https://www.qubes-os.org/doc/system-requirements/#qubes-release-4x) of Qubes 4.0, we previously announced
that we were extending (https://www.qubes-os.org/news/2016/09/02/4-0-minimum-requirements-3-2-extended-support/#extended-support-for-qubes-os-32) the support period for Qubes 3.2 to one full
year after the release of Qubes 4.0. Since Qubes 4.0 was released (https://www.qubes-os.org/news/2018/03/28/qubes-40/) on
2018-03-28, support for Qubes 3.2 is extended until 2019-03-28 (https://www.qubes-os.org/news/2018/03/28/qubes-40/#the-past-and-the-future).
Therefore, we strongly urge all current Qubes 3.2 users to upgrade to
Qubes 4.0 (https://www.qubes-os.org/doc/upgrade-to-r4.0/) before Qubes 3.2 reaches end-of-life (EOL) on 2019-03-28.
As always, the latest release is available on the downloads (https://www.qubes-os.org/downloads/) page.
https://www.qubes-os.org/news/2019/02/20/qubes-3-2-approaching-eol/
Qubes OS releases are normally supported (https://www.qubes-os.org/doc/supported-versions/) for six months after each
subsequent major or minor release (https://www.qubes-os.org/doc/version-scheme/). However, in light of the more
demanding system requirements (https://www.qubes-os.org/doc/system-requirements/#qubes-release-4x) of Qubes 4.0, we previously announced
that we were extending (https://www.qubes-os.org/news/2016/09/02/4-0-minimum-requirements-3-2-extended-support/#extended-support-for-qubes-os-32) the support period for Qubes 3.2 to one full
year after the release of Qubes 4.0. Since Qubes 4.0 was released (https://www.qubes-os.org/news/2018/03/28/qubes-40/) on
2018-03-28, support for Qubes 3.2 is extended until 2019-03-28 (https://www.qubes-os.org/news/2018/03/28/qubes-40/#the-past-and-the-future).
Therefore, we strongly urge all current Qubes 3.2 users to upgrade to
Qubes 4.0 (https://www.qubes-os.org/doc/upgrade-to-r4.0/) before Qubes 3.2 reaches end-of-life (EOL) on 2019-03-28.
As always, the latest release is available on the downloads (https://www.qubes-os.org/downloads/) page.
Xen Project 4.10.3 and 4.9.4 are available
https://blog.xenproject.org/2019/02/26/xen-project-4-10-3-and-4-9-4-are-available/
I am pleased to announce the release of Xen 4.10.3 and 4.9.4. Xen Project Maintenance releases are released in line with our Maintenance Release Policy. We recommend that all users of the 4.10 and 4.9 stable series update to the latest point release. These releases are available from their git repositories xenbits.xenproject.org/gitweb/?p=xen.git;a=shortlog;h=refs/heads/stable-4.10 (tag RELEASE-4.10.3) xenbits.xenproject.org/gitweb/?p=xen.git;a=shortlog;h=refs/heads/stable-4.9 […]
https://blog.xenproject.org/2019/02/26/xen-project-4-10-3-and-4-9-4-are-available/
I am pleased to announce the release of Xen 4.10.3 and 4.9.4. Xen Project Maintenance releases are released in line with our Maintenance Release Policy. We recommend that all users of the 4.10 and 4.9 stable series update to the latest point release. These releases are available from their git repositories xenbits.xenproject.org/gitweb/?p=xen.git;a=shortlog;h=refs/heads/stable-4.10 (tag RELEASE-4.10.3) xenbits.xenproject.org/gitweb/?p=xen.git;a=shortlog;h=refs/heads/stable-4.9 […]
Talk about Qubes in Stockholm tonight: https://www.meetup.com/Stockholm-Cybersecurity-Meetup/events/dwjxrqyzdbkc/
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
QSB #048: Multiple Xen vulnerabilities
https://www.qubes-os.org/news/2019/03/05/qsb-048/
We have just published Qubes Security Bulletin (QSB) #048:
Multiple Xen vulnerabilities.
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 #048 in the qubes-secpack:
https://github.com/QubesOS/qubes-secpack/blob/master/QSBs/qsb-048-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/
View the Xen Security Advisory (XSA) Tracker:
https://www.qubes-os.org/security/xsa/
---===[ Qubes Security Bulletin #48 ]===---
2019-03-05
Multiple Xen vulnerabilities
Summary
========
On 2019-03-05, the Xen Security Team published the following Xen
Security Advisories (XSAs):
XSA-285 [1] "race with pass-through device hotplug":
| When adding a passed-through PCI device to a domain after it was
| already started, IOMMU page tables may need constructing on the fly.
| For PV guests the decision whether a page ought to have a mapping is
| based on whether the page is writable, to prevent IOMMU access to
| things like page tables. Writablility of a page may, however, change
| at any time. Failure of the relevant code to respect this possible
| race may lead to IOMMU mappings of, in particular, page tables,
| allowing the guest to alter such page tables without Xen auditing the
| changes.
|
| Malicious PV guests can escalate their privilege to that of the
| hypervisor.
XSA-287 [2] "x86: steal_page violates page_struct access discipline":
| Xen's reference counting rules were designed to allow pages to change
| owner and state without requiring a global lock. Each page has a page
| structure, and a very specific set of access disciplines must be
| observed to ensure that pages are freed properly, and that no writable
| mappings exist for PV pagetable pages.
|
| Unfortunately, when the XENMEM_exchange hypercall was introduced,
| these access disciplines were violated, opening up several potential
| race conditions.
|
| A single PV guest can leak arbitrary amounts of memory, leading to a
| denial of service.
|
| A cooperating pair of PV and HVM/PVH guests can get a writable
| pagetable entry, leading to information disclosure or privilege
| escalation.
|
| Privilege escalation attacks using only a single PV guest or a pair of
| PV guests have not been ruled out.
|
| Note that both of these attacks require very precise timing, which may
| be difficult to exploit in practice.
XSA-288 [3] "x86: Inconsistent PV IOMMU discipline":
| In order for a PV domain to set up DMA from a passed-through device to
| one of its pages, the page must be mapped in the IOMMU. On the other
| hand, before a PV page may be used as a "special" page type (such as a
| pagetable or denoscriptor table), it _must not_ be writable in the IOMMU
| (otherwise a malicious guest could DMA arbitrary page tables into the
| memory, bypassing Xen's safety checks); and Xen's current rule is to
| have such pages not in the IOMMU at all.
|
| Until now, in order to accomplish this, the code has borrowed HVM
| domain's "physmap" concept: When a page is assigned to a guest,
| guess_physmap_add_entry() is called, which for PV guests, will create
| a writable IOMMU mapping; and when a page is removed,
| guest_physmap_remove_entry() is called, which will remove the mapping.
|
| Additionally, when a page gains the PGT_writable page type, the page
| will be added into the IOMMU; and when the page changes away from a
| PGT_writable type, the page will be removed from the IOMMU.
|
| Unfortunately, borrowing the "physmap" concept from HVM domains is
| problematic. HVM domains have a lock on their p2m tables, ensuring
https://www.qubes-os.org/news/2019/03/05/qsb-048/
We have just published Qubes Security Bulletin (QSB) #048:
Multiple Xen vulnerabilities.
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 #048 in the qubes-secpack:
https://github.com/QubesOS/qubes-secpack/blob/master/QSBs/qsb-048-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/
View the Xen Security Advisory (XSA) Tracker:
https://www.qubes-os.org/security/xsa/
---===[ Qubes Security Bulletin #48 ]===---
2019-03-05
Multiple Xen vulnerabilities
Summary
========
On 2019-03-05, the Xen Security Team published the following Xen
Security Advisories (XSAs):
XSA-285 [1] "race with pass-through device hotplug":
| When adding a passed-through PCI device to a domain after it was
| already started, IOMMU page tables may need constructing on the fly.
| For PV guests the decision whether a page ought to have a mapping is
| based on whether the page is writable, to prevent IOMMU access to
| things like page tables. Writablility of a page may, however, change
| at any time. Failure of the relevant code to respect this possible
| race may lead to IOMMU mappings of, in particular, page tables,
| allowing the guest to alter such page tables without Xen auditing the
| changes.
|
| Malicious PV guests can escalate their privilege to that of the
| hypervisor.
XSA-287 [2] "x86: steal_page violates page_struct access discipline":
| Xen's reference counting rules were designed to allow pages to change
| owner and state without requiring a global lock. Each page has a page
| structure, and a very specific set of access disciplines must be
| observed to ensure that pages are freed properly, and that no writable
| mappings exist for PV pagetable pages.
|
| Unfortunately, when the XENMEM_exchange hypercall was introduced,
| these access disciplines were violated, opening up several potential
| race conditions.
|
| A single PV guest can leak arbitrary amounts of memory, leading to a
| denial of service.
|
| A cooperating pair of PV and HVM/PVH guests can get a writable
| pagetable entry, leading to information disclosure or privilege
| escalation.
|
| Privilege escalation attacks using only a single PV guest or a pair of
| PV guests have not been ruled out.
|
| Note that both of these attacks require very precise timing, which may
| be difficult to exploit in practice.
XSA-288 [3] "x86: Inconsistent PV IOMMU discipline":
| In order for a PV domain to set up DMA from a passed-through device to
| one of its pages, the page must be mapped in the IOMMU. On the other
| hand, before a PV page may be used as a "special" page type (such as a
| pagetable or denoscriptor table), it _must not_ be writable in the IOMMU
| (otherwise a malicious guest could DMA arbitrary page tables into the
| memory, bypassing Xen's safety checks); and Xen's current rule is to
| have such pages not in the IOMMU at all.
|
| Until now, in order to accomplish this, the code has borrowed HVM
| domain's "physmap" concept: When a page is assigned to a guest,
| guess_physmap_add_entry() is called, which for PV guests, will create
| a writable IOMMU mapping; and when a page is removed,
| guest_physmap_remove_entry() is called, which will remove the mapping.
|
| Additionally, when a page gains the PGT_writable page type, the page
| will be added into the IOMMU; and when the page changes away from a
| PGT_writable type, the page will be removed from the IOMMU.
|
| Unfortunately, borrowing the "physmap" concept from HVM domains is
| problematic. HVM domains have a lock on their p2m tables, ensuring
| synchronization between modifications to the p2m; and all hypercall
| parameters must first be translated through the p2m before being used.
| Trying to mix this locked-and-gated approach with PV's lock-free
| approach leads to several races and inconsistencies.
|
| An untrusted PV domain with access to a physical device can DMA into
| its own pagetables, leading to privilege escalation.
XSA-292 [4] "x86: insufficient TLB flushing when using PCID"
| Use of Process Context Identifiers (PCID) was introduced into Xen in
| order to improve performance after XSA-254 (and in particular its
| Meltdown sub-issue). This enablement implied changes to the TLB
| flushing logic. The particular case of context switch to a vCPU of a
| PCID-enabled guest left open a time window between the full TLB flush,
| and the actual address space switch, during which additional TLB
| entries (from the address space about to be switched away from) can be
| accumulated, which will not subsequently be purged.
|
| Malicious PV guests may be able to cause a host crash (Denial of
| Service) or to gain access to data pertaining to other guests.
| Privilege escalation opportunities cannot be ruled out.
|
| Additionally, vulnerable configurations are likely to be unstable even
| in the absence of an attack.
Impact on Qubes OS
===================
XSA-285 and XSA-288 do not affect Qubes OS 4.0 in its default
configuration, since they require a PV domain with a PCI device.
Moreover, in order to take advantage of XSA-285, the user would have to
assign a PCI device to a PV domain while it was running. Such an
operation is disabled in the Qubes GUI tools and discouraged in the
Qubes documentation. [5]
XSA-287 and XSA-292 affect only PV domains, which are used only for
stubdomains in the default Qubes OS 4.0 configuration. This means that
an attacker would first have to compromise a stubdomain in order to
attack Xen by exploiting these vulnerabilities. Nevertheless, since it
is possible to manually create PV domains in Qubes OS 4.0, we consider
XSA-287 and XSA-292 to affect Qubes OS 4.0.
All four of these XSAs affect Qubes OS 3.2.
Patching
=========
The specific packages that resolve the problems discussed in this
bulletin are as follows:
For Qubes OS 4.0:
- Xen packages version 4.8.5-3
For Qubes OS 3.2:
- Xen packages version 4.6.6-46
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.
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 Advisories.
References
===========
[1] https://xenbits.xen.org/xsa/advisory-285.html
[2] https://xenbits.xen.org/xsa/advisory-287.html
[3] https://xenbits.xen.org/xsa/advisory-288.html
[4] https://xenbits.xen.org/xsa/advisory-292.html
[5] https://www.qubes-os.org/doc/assigning-devices/
--
The Qubes Security Team
https://www.qubes-os.org/security/
| parameters must first be translated through the p2m before being used.
| Trying to mix this locked-and-gated approach with PV's lock-free
| approach leads to several races and inconsistencies.
|
| An untrusted PV domain with access to a physical device can DMA into
| its own pagetables, leading to privilege escalation.
XSA-292 [4] "x86: insufficient TLB flushing when using PCID"
| Use of Process Context Identifiers (PCID) was introduced into Xen in
| order to improve performance after XSA-254 (and in particular its
| Meltdown sub-issue). This enablement implied changes to the TLB
| flushing logic. The particular case of context switch to a vCPU of a
| PCID-enabled guest left open a time window between the full TLB flush,
| and the actual address space switch, during which additional TLB
| entries (from the address space about to be switched away from) can be
| accumulated, which will not subsequently be purged.
|
| Malicious PV guests may be able to cause a host crash (Denial of
| Service) or to gain access to data pertaining to other guests.
| Privilege escalation opportunities cannot be ruled out.
|
| Additionally, vulnerable configurations are likely to be unstable even
| in the absence of an attack.
Impact on Qubes OS
===================
XSA-285 and XSA-288 do not affect Qubes OS 4.0 in its default
configuration, since they require a PV domain with a PCI device.
Moreover, in order to take advantage of XSA-285, the user would have to
assign a PCI device to a PV domain while it was running. Such an
operation is disabled in the Qubes GUI tools and discouraged in the
Qubes documentation. [5]
XSA-287 and XSA-292 affect only PV domains, which are used only for
stubdomains in the default Qubes OS 4.0 configuration. This means that
an attacker would first have to compromise a stubdomain in order to
attack Xen by exploiting these vulnerabilities. Nevertheless, since it
is possible to manually create PV domains in Qubes OS 4.0, we consider
XSA-287 and XSA-292 to affect Qubes OS 4.0.
All four of these XSAs affect Qubes OS 3.2.
Patching
=========
The specific packages that resolve the problems discussed in this
bulletin are as follows:
For Qubes OS 4.0:
- Xen packages version 4.8.5-3
For Qubes OS 3.2:
- Xen packages version 4.6.6-46
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.
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 Advisories.
References
===========
[1] https://xenbits.xen.org/xsa/advisory-285.html
[2] https://xenbits.xen.org/xsa/advisory-287.html
[3] https://xenbits.xen.org/xsa/advisory-288.html
[4] https://xenbits.xen.org/xsa/advisory-292.html
[5] https://www.qubes-os.org/doc/assigning-devices/
--
The Qubes Security Team
https://www.qubes-os.org/security/
XSAs 284, 290, 291, 293, and 294 do not affect the security of Qubes OS
https://www.qubes-os.org/news/2019/03/05/xsa-284-290-291-293-294-qubes-not-affected/
The Xen Project has published Xen Security Advisories 284, 290, 291,
293, and 294 (XSA-284, XSA-290, XSA-291, XSA-293, and XSA-294,
respectively). These XSAs do not affect the security of Qubes OS,
and no user action is necessary.
These XSAs have been added to the XSA Tracker (https://www.qubes-os.org/security/xsa/):
https://www.qubes-os.org/security/xsa/#284
https://www.qubes-os.org/security/xsa/#290
https://www.qubes-os.org/security/xsa/#291
https://www.qubes-os.org/security/xsa/#293
https://www.qubes-os.org/security/xsa/#294
https://www.qubes-os.org/news/2019/03/05/xsa-284-290-291-293-294-qubes-not-affected/
The Xen Project has published Xen Security Advisories 284, 290, 291,
293, and 294 (XSA-284, XSA-290, XSA-291, XSA-293, and XSA-294,
respectively). These XSAs do not affect the security of Qubes OS,
and no user action is necessary.
These XSAs have been added to the XSA Tracker (https://www.qubes-os.org/security/xsa/):
https://www.qubes-os.org/security/xsa/#284
https://www.qubes-os.org/security/xsa/#290
https://www.qubes-os.org/security/xsa/#291
https://www.qubes-os.org/security/xsa/#293
https://www.qubes-os.org/security/xsa/#294
Xen Project 4.10.3 and 4.9.4 are available
https://xenproject.org/2019/02/25/xen-project-4-10-2-and-4-9-3-are-available-2/
https://xenproject.org/2019/02/25/xen-project-4-10-2-and-4-9-3-are-available-2/
Revolutionizing the Auto Industry with Open Source: EPAM’s Xen Powered Virtual Cockpit
https://xenproject.org/2019/03/12/revolutionizing-the-auto-industry-with-open-source-epams-xen-powered-virtual-cockpit/
EPAM, a global provider of software engineering and IT consulting services, is making strides in the auto industry by connecting the infotainment side of the car and the safety side...
https://xenproject.org/2019/03/12/revolutionizing-the-auto-industry-with-open-source-epams-xen-powered-virtual-cockpit/
EPAM, a global provider of software engineering and IT consulting services, is making strides in the auto industry by connecting the infotainment side of the car and the safety side...
Qubes Tor onion services will no longer be maintained
https://www.qubes-os.org/news/2019/03/24/tor-onion-services-no-longer-maintained/
We regret to announce that the Qubes Tor onion services will no longer
be maintained due to lack of resources. This includes all Qubes onion
services, including the Qubes website onion mirror and the onion package
repos.
We would like to thank the Whonix Project for generously maintaining
these services for over a year (https://www.qubes-os.org/news/2018/01/23/qubes-whonix-next-gen-tor-onion-services/). Maintaining the Tor
onion services requires labor, servers, and bandwidth. Unfortunately,
none of these resources are available to the Qubes OS or Whonix projects
in sufficient quantities to allow us to continue offering these
services.
We recommend that users who currently rely on any Qubes onion addresses
transition to the corresponding clearnet addresses immediately.
https://www.qubes-os.org/news/2019/03/24/tor-onion-services-no-longer-maintained/
We regret to announce that the Qubes Tor onion services will no longer
be maintained due to lack of resources. This includes all Qubes onion
services, including the Qubes website onion mirror and the onion package
repos.
We would like to thank the Whonix Project for generously maintaining
these services for over a year (https://www.qubes-os.org/news/2018/01/23/qubes-whonix-next-gen-tor-onion-services/). Maintaining the Tor
onion services requires labor, servers, and bandwidth. Unfortunately,
none of these resources are available to the Qubes OS or Whonix projects
in sufficient quantities to allow us to continue offering these
services.
We recommend that users who currently rely on any Qubes onion addresses
transition to the corresponding clearnet addresses immediately.