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

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

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 […]

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 […]

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. […]

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. […]

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

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/

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.

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 […]

Talk about Qubes in Stockholm tonight: https://www.meetup.com/Stockholm-Cybersecurity-Meetup/events/dwjxrqyzdbkc/

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

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

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

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/

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

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.

Qubes OS 3.2 has reached EOL
https://www.qubes-os.org/news/2019/03/28/qubes-3-2-has-reached-eol/

Qubes OS 3.2 has officially reached end-of-life (EOL). 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/) immediately.
As always, the support statuses of all Qubes OS and TemplateVM versions
are available on the Supported Versions (https://www.qubes-os.org/doc/supported-versions/) page, and the latest release
is available on the Downloads (https://www.qubes-os.org/downloads/) page.

Previous announcements:
Extended Support for Qubes OS 3.2 (https://www.qubes-os.org/news/2016/09/02/4-0-minimum-requirements-3-2-extended-support/#extended-support-for-qubes-os-32)
Qubes 4.0: The Past and the Future (https://www.qubes-os.org/news/2018/03/28/qubes-40/#the-past-and-the-future)
Qubes 3.2 approaching EOL on 2019-03-28 (https://www.qubes-os.org/news/2018/02/20/qubes-3-2-approaching-eol)

Xen Project Hypervisor 4.12 Offers Smaller Code Size and Improved Security
https://xenproject.org/2019/04/02/xen-project-hypervisor-4-12-offers-smaller-code-size-and-improved-security/

Major release makes Xen an attractive option for automotive and embedded technologies. SAN FRANCISCO – April 2, 2019 — The Xen Project, an open source hypervisor hosted at the Linux...