Dear Qubes Community,

We have just published Qubes Security Bulletin (QSB) #42: Linux netback driver OOB access in hash handling (XSA-270). 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 #42 in the qubes-secpack:

https://github.com/QubesOS/qubes-secpack/blob/master/QSBs/qsb-042-2018.txt

Learn about the qubes-secpack, including how to obtain, verify, and read it:

https://www.qubes-os.org/security/pack/

View all past QSBs:

https://www.qubes-os.org/security/bulletins/

View XSA-270 in the XSA Tracker:

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

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

                             2018-08-14


      Linux netback driver OOB access in hash handling (XSA-270)

Summary
========

On 2018-08-14, the Xen Security Team published Xen Security Advisory
270 (XSA-270) [1] with the following description:

| Linux's netback driver allows frontends to control mapping of requests
| to request queues.  When processing a request to set or change this
| mapping, some input validation was missing or flawed.
| 
| A malicious or buggy frontend may cause the (usually privileged)
| backend to make out of bounds memory accesses, potentially resulting
| in one or more of privilege escalation, Denial of Service (DoS), or
| information leaks.

Impact for Qubes
=================

The bug affects only the network backend driver, which means that any
qube with access to a network can attack the qube that provides it with
access to that network. For example:

 - In a default configuration, any network-connected AppVM can attack
   sys-firewall, which can in turn attack sys-net.

 - Any qube connected to a VPN Gateway [2] can attack the VPN Gateway
   and potentially steal VPN credentials.

 - Any Whonix Workstation can attack the Whonix Gateway to which it is
   connected, potentially compromising anonymity.

It is important to note, however, that dom0 and network-disconnected
qubes are not affected.

Patching
=========

The Xen Project has provided patches to fix this issue.

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

  For Qubes 3.2:
  - kernel packages, version 4.14.57-2
  - kernel-latest packages, version 4.17.9-2

  For Qubes 4.0:
  - kernel packages, version 4.14.57-2
  - kernel-latest packages, version 4.17.9-2

The kernel-latest packages are not installed by default. If you do not
already have them installed, then it is not necessary to install them in
order to fix this issue. However, if you already have them installed,
then we recommend that you update them to the version containing the fix
for this issue.

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 restart of all network-providing qubes 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
Linux binaries.

Users who are using in-VM kernels [3] for any of their VMs should note
that installing the packages listed above will not update their in-VM
kernels. We recommend that these users install updates for their in-VM
kernels when the appropriate distributions provide kernel updates that
fix this issue.

Credits
========

See the original Xen Security Advisory.

References
===========

[1] https://xenbits.xen.org/xsa/advisory-270.html
[2] https://www.qubes-os.org/doc/vpn/
[3] https://www.qubes-os.org/doc/managing-vm-kernel/#using-kernel-installed-in-the-vm-r40

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