Dear Qubes Community,
We have just published Qubes Security Bulletin (QSB) #33: Xen hypervisor (XSA-231 through XSA-234). 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 #33 in the qubes-secpack:
Learn about the qubes-secpack, including how to obtain, verify, and read it:
View all past QSBs:
View XSA-231 through XSA-234 in the XSA Tracker:
---===[ Qubes Security Bulletin #33 ]===--- September 12, 2017 Xen hypervisor (XSA-231 through XSA-234) Summary ======== The Xen Security Team released several Xen Security Advisories today (XSA-231 through XSA-234). The impact of these advisories ranges from system crashes to privilege escalations. See our commentary below for details. Technical details ================== Xen Security Advisory 231 : | The function `alloc_heap_pages` allows callers to specify the first | NUMA node that should be used for allocations through the `memflags` | parameter; the node is extracted using the `MEMF_get_node` macro. | | While the function checks to see if the special constant | `NUMA_NO_NODE` is specified, it otherwise does not handle the case | where `node >= MAX_NUMNODES`. This allows an out-of-bounds access | to an internal array. | | An attacker using crafted hypercalls can execute arbitrary code within | Xen. Xen Security Advisory 232 : | The function `__gnttab_cache_flush` handles GNTTABOP_cache_flush grant | table operations. It checks to see if the calling domain is the owner | of the page that is to be operated on. If it is not, the owner's grant | table is checked to see if a grant mapping to the calling domain | exists for the page in question. | | However, the function does not check to see if the owning domain | actually has a grant table or not. Some special domains, such as | `DOMID_XEN`, `DOMID_IO` and `DOMID_COW` are created without grant | tables. Hence, if __gnttab_cache_flush operates on a page owned by | these special domains, it will attempt to dereference a null pointer | in the domain struct. | | The guest can get Xen to dereference a NULL pointer. | | For ARM guests, and x86 HVM guests, and x86 PV guests on systems with | SMAP enabled, this will cause a host crash (denial-of-service). | | For x86 PV guests on systems without SMAP enabled, an attacker can map | a crafted grant structure at virtual address 0. This can be leveraged | to increment an arbitrary virtual address, which can then probably be | leveraged into a full privilege escalation. Xen Security Advisory 234 : | When removing or replacing a grant mapping, the x86 PV specific path | needs to make sure page table entries remain in sync with other | accounting done. Although the identity of the page frame was | validated correctly, neither the presence of the mapping nor page | writability were taken into account. | | A malicious or buggy x86 PV guest could escalate its privileges or | crash the hypervisor. The Xen Security Team also released Xen Security Advisory 233 , with only DoS impact: | When shutting down a VM with a stubdomain, a race in cxenstored may | cause a double-free. | | The xenstored daemon may crash, resulting in a DoS of any parts of the | system relying on it (including domain creation / destruction, | ballooning, device changes, etc). Commentary from the Qubes Security Team ======================================== This batch of Xen security advisories reassures us in our decision to abandon default para-virtualization (PV) in Qubes 4.0. Indeed, only one of the potential privilege-escalation bugs discussed in this advisory affects non-PV virtualization: XSA-231. This bug is a prime example of the common problems associated with expanding the codebase in order to implement "exotic" functionality (in this case, NUMA support). While the Xen Project has made some progress recently in allowing extra features to be disabled at compile time, the code for NUMA support could not easily be deactivated, which is the reason for the inclusion of this bug in today's advisory. While the departure from para-virtualization (PV) in Qubes 4.0 will obviate many such vulnerabilities in the future, please note that Qubes 3.2 (the current, stable version of Qubes) still uses PV mode for most of the VMs. Therefore, all the bugs in this bulletin affect Qubes 3.2, and users should patch immediately. Compromise Recovery ==================== Starting with Qubes 3.2, we offer Paranoid Backup Restore Mode, which was designed specifically to aid in the recovery of a (potentially) compromised Qubes OS system. Thus, if you believe your system might have been compromised (perhaps because of the bugs discussed in this bulletin), then you should read and follow the procedure described here: https://www.qubes-os.org/news/2017/04/26/qubes-compromise-recovery/ Patching ========= The specific packages that resolve the problems discussed in this bulletin are as follows: For Qubes 3.2: - Xen packages, version 4.6.6-30 For Qubes 4.0: - Xen packages, version 4.8.2-2 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 Advisories. References ===========  https://xenbits.xen.org/xsa/advisory-231.html  https://xenbits.xen.org/xsa/advisory-232.html  https://xenbits.xen.org/xsa/advisory-233.html  https://xenbits.xen.org/xsa/advisory-234.html -- The Qubes Security Team https://www.qubes-os.org/security/