- Xen packages, version 4.8.5-12
- microcode_ctl 2.1-29.qubes1

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-305.html

--
The Qubes Security Team
https://www.qubes-os.org/security/

XSA-304 does not affect the security of Qubes OS
https://www.qubes-os.org/news/2019/11/13/xsa-304-qubes-not-affected/

The Xen Project has published Xen Security Advisory 304 (XSA-304).
This XSA does not affect the security of Qubes OS, and no user
action is necessary.

This XSA has been added to the XSA Tracker (https://www.qubes-os.org/security/xsa/):

https://www.qubes-os.org/security/xsa/#304

Support Group!

https://news.1rj.ru/str/joinchat/B8FHpkEToMfgdREGV7wzRQ

QSB #054: Xen fix for XSA-302 found ineffective in Qubes configuration (XSA-306)
https://www.qubes-os.org/news/2019/11/26/qsb-054/

We have just published Qubes Security Bulletin (QSB) #054:
Xen fix for XSA-302 found ineffective in Qubes configuration (XSA-306).
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 #054 in the qubes-secpack:

https://github.com/QubesOS/qubes-secpack/blob/master/QSBs/qsb-054-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 XSA-306 in the XSA Tracker:

https://www.qubes-os.org/security/xsa/#306



---===[ Qubes Security Bulletin #54 ]===---

2019-11-26


Xen fix for XSA-302 found ineffective in Qubes configuration (XSA-306)

Summary
========

In the course of re-verifying the fixes for QSB #52 (XSA-299, XSA-302)
[1], the Qubes Security Team discovered that the fix released by the
Xen Project for XSA-302 [2] is not effective for the configuration used
in Qubes OS.

On 2019-11-26, the Xen Security Team published the following Xen
Security Advisory (XSA):

XSA-306 [3] "Device quarantine for alternate pci assignment methods":
| XSA-302 relies on the use of libxl's "assignable-add" feature to
| prepare devices to be assigned to untrusted guests.
|
| Unfortunately, this is not considered a strictly required step for
| device assignment. The PCI passthrough documentation on the wiki
| describes alternate ways of preparing devices for assignment, and
| libvirt uses its own ways as well. Hosts where these "alternate"
| methods are used will still leave the system in a vulnerable state
| after the device comes back from a guest.
|
| An untrusted domain with access to a physical device can DMA into host
| memory, leading to privilege escalation.


Impact
=======

The original XSA-302 fix provided by the Xen Project is ineffective for
the configuration used in Qubes OS. Therefore, the impact is the same as
as the XSA-302 impact originally reported in QSB #52 (XSA-299, XSA-302).


Discussion
===========

The Qubes Security Team discovered this issue while re-verifying the Xen
Project's fixes for XSA-302. At that time, both XSA-302 and QSB #52 had
already been made public. Whether a disclosure has been made public is
significant to the Xen Security Policy [4]. Therefore, after discussion
with the Xen Security Team, we have decided to treat this as a separate
security issue, with a separate XSA, QSB, and embargo period.

From a security perspective, the new proposed fix for PCI device
isolation is much less fragile, since it no longer depends on toolstack
(libxl) behavior anymore.


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-13

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://github.com/QubesOS/qubes-secpack/blob/master/QSBs/qsb-052-2019.txt
[2] https://xenbits.xen.org/xsa/advisory-302.html
[3] https://xenbits.xen.org/xsa/advisory-306.html
[4] https://xenproject.org/developers/security-policy/

--

The Qubes Security Team
https://www.qubes-os.org/security/

Fedora 29 has reached EOL
https://www.qubes-os.org/news/2019/11/29/fedora-29-eol/

Fedora 29 has reached EOL (end-of-life (https://fedoraproject.org/wiki/End_of_life)). We strongly recommend that
all Qubes users upgrade their Fedora 29 TemplateVMs and StandaloneVMs to
Fedora 30 immediately. We provide step-by-step upgrade instructions for
upgrading Fedora TemplateVMs (https://www.qubes-os.org/doc/template/fedora/upgrade/). 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 30 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 switch all qubes
that were using the old template to use the new one (https://www.qubes-os.org/doc/templates/#switching).

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

Xen Project 4.11.3 is available!
https://xenproject.org/2019/11/29/xen-project-4-11-3-is-available/

I am pleased to announce the release of the Xen 4.11.3. Xen Project maintenance releases are released in line with our Maintenance Release Policy. We recommend that all users of...

QSB #055: Issues with PV type change and handling IOMMU on AMD (XSA-310, XSA-311)
https://www.qubes-os.org/news/2019/12/11/qsb-055/

We have just published Qubes Security Bulletin (QSB) #055:
Issues with PV type change and handling IOMMU on AMD (XSA-310, XSA-311).
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 #055 in the qubes-secpack:

https://github.com/QubesOS/qubes-secpack/blob/master/QSBs/qsb-055-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 XSA-310 and XSA-311 in the XSA Tracker:

https://www.qubes-os.org/security/xsa/#310
https://www.qubes-os.org/security/xsa/#311



---===[ Qubes Security Bulletin #55 ]===---

2019-12-11


Issues with PV type change and handling IOMMU on AMD (XSA-310, XSA-311)


Summary
========

On 2019-12-11, the Xen Security Team published the following Xen
Security Advisories (XSAs):

XSA-310 (CVE-2019-19580) [1] Further issues with restartable PV type
change operations:

| XSA-299 addressed several critical issues in restartable PV type
| change operations. Despite extensive testing and auditing, some
| corner cases were missed.
|
| A malicious PV guest administrator may be able to escalate their
| privilege to that of the host.

XSA-311 (CVE-2019-19577) [2] Bugs in dynamic height handling for AMD
IOMMU pagetables:

| When running on AMD systems with an IOMMU, Xen attempted to
| dynamically adapt the number of levels of pagetables (the pagetable
| height) in the IOMMU according to the guest's address space size. The
| code to select and update the height had several bugs.
|
| Notably, the update was done without taking a lock which is necessary
| for safe operation.
|
| A malicious guest administrator can cause Xen to access data
| structures while they are being modified, causing Xen to crash.
| Privilege escalation is thought to be very difficult but cannot be
| ruled out.
|
| Additionally, there is a potential memory leak of 4kb per guest boot,
| under memory pressure.


Impact
=======

XSA-310 applies only to PV domains. Most of the domains in Qubes 4.0 are
PVH or HVM domains and are therefore not affected by XSA-310. However,
PV domains are still supported in Qubes 4.0, and they are specifically
used to host Qemu-instance-supporting HVM domains.

In the default Qubes 4.0 setup, several attacks would have to be chained
together in order to exploit this vulnerability. Specifically, an
attacker would have to:

1. Take control of an HVM domain, e.g., sys-usb, sys-net, or a
user-created HVM domain. (Most user domains are PVH and are therefore
not affected.)

2. Successfully attack a Qemu instance running in an associated PV
stubdomain.

3. Finally, find some way to exploit the vulnerability described in
XSA-310.

Moreover, since this vulnerability is a race condition, it is an
unreliable attack vector in real world scenarios.

XSA-311 affects only systems running on AMD hardware and also is
thought to be very hard to exploit. But since it can't be ruled out
completely, we recommend applying updates nevertheless.


Patching
=========

The specific packages that resolve the problems discussed in this
bulletin are as follows:

For Qubes 4.0:
- Xen packages, version 4.8.5-14

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-310.html
[2] https://xenbits.xen.org/xsa/advisory-311.html

--
The Qubes Security Team
https://www.qubes-os.org/security/

Qubes OS 4.0.2-rc3 has been released!
https://www.qubes-os.org/news/2019/12/13/qubes-4-0-2-rc3/

We’re pleased to announce the third release candidate for Qubes 4.0.2!

Features:
All 4.0 dom0 updates to date
Fedora 30 TemplateVM
Debian 10 TemplateVM
Whonix 15 Gateway and Workstation TemplateVMs
Linux kernel 4.19 by default
Qubes 4.0.2-rc3 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.2.

What should I do?

If you installed Qubes 4.0 or 4.0.1 and have fully updated (https://www.qubes-os.org/doc/updating-qubes-os/), then
your system is already equivalent to a Qubes 4.0.2 installation. No
further action is required.

Regardless of your current OS, if you wish to install (or reinstall)
Qubes 4.0 for any reason, then the 4.0.2 ISO makes this more convenient
and secure, since it bundles all Qubes 4.0 updates to date.

Note: At 4.5 GiB, the Qubes 4.0.2-rc3 ISO will not fit on a
single-layer DVD (for the technical details underlying this, please see
issue #5367 (https://github.com/QubesOS/qubes-issues/issues/5367)). Instead, we recommend copying the ISO onto a
sufficiently large USB drive (https://www.qubes-os.org/doc/installation-guide/#copying-the-iso-onto-the-installation-medium). However, if you would prefer to
use optical media, we suggest selecting a dual-layer DVD or Blu-ray disc.

Release candidate planning

If no major issues are discovered in 4.0.2-rc3, we expect the stable
release of 4.0.2 to follow in a few weeks. As usual, you can help by
reporting any bugs you encounter (https://www.qubes-os.org/doc/reporting-bugs/).

True static partitioning with Xen Dom0-less
https://xenproject.org/2019/12/16/true-static-partitioning-with-xen-dom0-less/

The Xen Project hypervisor has relied on a special virtual machine, Dom0, to perform privileged operations since the early days of the project. Dom0 has always been the very first...

What’s New in Xen 4.13
https://xenproject.org/2019/12/18/whats-new-in-xen-4-13/

I am pleased to announce the release of Xen Project Hypervisor 4.13. This latest release improves security, hardware support, added new options for embedded use cases and reflects a wide...

Xen Project Hypervisor 4.13 Brings Improved Security, Hardware Support and Features to Increase Embedded Use Case Adoption
https://xenproject.org/2019/12/18/xen-project-hypervisor-4-13-brings-improved-security-hardware-support-and-features-to-increase-embedded-use-case-adoption/

Broad community collaboration brings new functionality as well as steps forward in functional safety certification. SAN FRANCISCO – December 18, 2019 — The Xen Project, an open source hypervisor hosted...

QSB #056: Insufficient anti-spoofing firewall rules
https://www.qubes-os.org/news/2019/12/25/qsb-056/

We have just published Qubes Security Bulletin (QSB) #056:
Insufficient anti-spoofing firewall rules.
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 #056 in the qubes-secpack:

https://github.com/QubesOS/qubes-secpack/blob/master/QSBs/qsb-056-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 #56]===---

2019-12-25

Insufficient anti-spoofing firewall rules

Summary
=======

The firewall configuration in Qubes OS prevents IP address spoofing in
downstream interfaces (e.g., network-providing qubes, network-consuming
qubes, and `vif*` interfaces). However, it does not prevent IP spoofing
in upstream interfaces (normally `eth0`, but in the case of VPNs or
other configuration, there may also be others).


Impact
======

Configurations with inter-VM networking allowed [1] or additional
interfaces created (e.g., VPNs) are vulnerable to IP spoofing. Combined
with other vulnerabilities, such as the procedure described in the
CVE-2019-14899 report [2], this could allow an upstream qube (e.g.,
sys-net) to inject data into an established connection.


Discussion
==========

The anti-spoofing firewall rules in a network-providing qube look like
this:

*raw
...
-A PREROUTING ! -s 10.137.0.5/32 -i vif12.0 -j DROP
-A PREROUTING ! -s 10.137.0.6/32 -i vif17.0 -j DROP
-A PREROUTING ! -s 10.137.0.7/32 -i vif18.0 -j DROP
-A PREROUTING ! -s 10.137.0.8/32 -i vif21.0 -j DROP
COMMIT

Each `vif*` interface drops packets if its source IP does not match the
one assigned to the qube behind that interface. However, it does not
ensure that the source IP does not appear on any other (non-`vif`)
interface.

The other property could, in theory, be achieved by this FORWARD chain:

*filter
...
-A FORWARD -m conntrack --ctstate RELATED,ESTABLISHED -j ACCEPT
-A FORWARD -j QBS-FORWARD
-A FORWARD -i vif+ -o vif+ -j DROP
-A FORWARD -i vif+ -j ACCEPT
-A FORWARD -j DROP
COMMIT

These rules should reject packets not belonging to established
connections on non-vif interfaces. Moreover, without seeing other
packets in the connection, it should be prohibitively difficult to forge
packets that would be considered to be part of an established
connection. However, methods like the one described in the
CVE-2019-14899 report [2] allow one to guess the required parameters.
Note that if a connection normally goes through a given qube (without
any further protection like TLS), that qube can always manipulate the
traffic without guessing anything.

The default Qubes configuration is secure, since network traffic either
goes directly to the upstream qube (which, by definition, has access to
that traffic), or it is an inter-VM connection attempt, which is
prevented by the third rule (meaning that there are no connections in
the conntrack table that the upstream qube could try to hijack).
However, once the user departs from the default configuration, e.g., by
introducing inter-VM communications [1] (allowing traffic between some
`vif*` interfaces), or VPN-like interfaces, the default rules are no
longer sufficient, since an upstream qube can inject packets (by
spoofing the source IP) into connections that normally do not pass
through it in the clear.

Our solution to this problem is twofold:

1. For Qubes OS 4.0, whenever a running qube is connected to a
network-providing qube, an additional firewall rule is added that
blocks the running qube's IP as a source on other network interfaces.

2. For Qubes OS 4.1 and later, we will modify the firewall mechanism so

that it maintains aa list of connected qubes and their addresses,
even when they are not running. All such addresses will be rejected
on upstream network interfaces.

The main difference between these two solutions is that fix for Qubes OS
4.0 does not protect against spoofing the addresses of qubes that are
not running. However, since 4.0 is a stable release, we must consider
the impact of such a solution on the stability of this release. This fix
is a much simpler change that carries a considerably lower risk of
introducing a regression.


Patching
========

The specific packages that resolve the problems discussed in this
bulletin are as follows:

For Qubes OS 4.0:
- qubes-core-agent version 4.0.51

The packages for domUs are to be installed in TemplateVMs and
StandaloneVMs via the Qube Manager or via their respective package
managers:

For updates to Fedora from the stable repository
(not immediately available):
$ sudo dnf update

For updates to Fedora from the security-testing repository:
$ sudo dnf update --enablerepo=qubes-vm-*-security-testing

For updates to Debian from the stable repository
(not immediately available):
$ sudo apt update && sudo apt dist-upgrade

For updates to Debian from the security-testing repository:
First, uncomment the line below "Qubes security updates testing
repository" in:
/etc/apt/sources.list.d/qubes-r*.list
Then:
$ sudo apt update && sudo apt dist-upgrade

A restart is required for these changes to take effect. This entails
shutting down the TemplateVM before restarting all the TemplateBasedVMs
based on that TemplateVM.

These packages will migrate from the security-testing repositories to
their respective current (stable) repositories over the next two weeks
after being tested by the community.


Credits
========

The issue was reported by Demi Marie Obenour.


References
==========

[1] https://www.qubes-os.org/doc/firewall/#enabling-networking-between-two-qubes
[2] https://nvd.nist.gov/vuln/detail/CVE-2019-14899

--
The Qubes Security Team
https://www.qubes-os.org/security/

Qubes OS 4.0.2 has been released!
https://www.qubes-os.org/news/2020/01/02/qubes-4-0-2/

We’re pleased to announce the release of Qubes 4.0.2! This is the second
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
Fedora 30 TemplateVM
Debian 10 TemplateVM
Whonix 15 Gateway and Workstation TemplateVMs
Linux kernel 4.19 by default
Qubes 4.0.2 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.2.

What should I do?

If you installed Qubes 4.0 or 4.0.1 and have fully updated (https://www.qubes-os.org/doc/updating-qubes-os/), then
your system is already equivalent to a Qubes 4.0.2 installation. No
further action is required.

Similarly, if you’re currently using a Qubes 4.0.2 release candidate
(4.0.2-rc1, 4.0.2-rc2, or 4.0.2-rc3), and your system is fully
updated (https://www.qubes-os.org/doc/updating-qubes-os/), then your system is equivalent to a 4.0.2 stable installation,
and no additional 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.2 ISO makes this more convenient
and secure, since it bundles all Qubes 4.0 updates to date.

Note: At 4.5 GiB, the Qubes 4.0.2 ISO will not fit on a
single-layer DVD (for the technical details underlying this, please see
issue #5367 (https://github.com/QubesOS/qubes-issues/issues/5367)). Instead, we recommend copying the ISO onto a
sufficiently large USB drive (https://www.qubes-os.org/doc/installation-guide/#copying-the-iso-onto-the-installation-medium). However, if you would prefer to
use optical media, we suggest selecting a dual-layer DVD or Blu-ray disc.

Thank you to all the release candidate users for testing this release
and reporting issues (https://www.qubes-os.org/doc/reporting-bugs/)!

Xen Project 4.12.2 is available!
https://xenproject.org/2020/01/03/xen-project-4-12-2-is-available/

I am pleased to announce the release of the Xen 4.12.2. Xen Project maintenance releases are released in line with our Maintenance Release Policy. We recommend that all users of...

The Xen Project: A decade of innovation and looking forward to 2020 and beyond
https://xenproject.org/2020/01/07/the-xen-project-a-decade-of-innovation-and-looking-forward-to-2020-and-beyond/

As we enter a new decade, it is worthwhile to look back at the last year and decade to glance into the crystal ball for what 2020 and beyond may...