Permalink
Switch branches/tags
w_49cc5d5a mm_78525939 mm_61621ebb mm_51660c83 mm_15143d72 mm_692db79a mm_201e4cc3 mm_109b6fdf mm_89af9f06 mm_49cc5d5a mm_40b3338e mm_7c825880 mm_5f208b29 mm_3bd7fe2e mm_2beab537 mm_1e390705 mm_d9c2f7df mm_d5a7241a mm_a4e175f3 marmarek_sec_84308824 marmarek_sec_78525939 marmarek_sec_46658321 marmarek_sec_24681439 marmarek_sec_6325034c marmarek_sec_4472371a marmarek_sec_539649d9 marmarek_sec_0311584c marmarek_sec_287158a9 marmarek_sec_162930b6 marmarek_sec_81194e72 marmarek_sec_61621ebb marmarek_sec_51660c83 marmarek_sec_43373e67 marmarek_sec_42521f68 marmarek_sec_15143d72 marmarek_sec_9097bd53 marmarek_sec_8487a05e marmarek_sec_5539bfe8 marmarek_sec_4506ce8d marmarek_sec_2245aeed marmarek_sec_1302b8c6 marmarek_sec_880c1d9d marmarek_sec_848e7753 marmarek_sec_813f2ae3 marmarek_sec_806ab1a4 marmarek_sec_786ae750 marmarek_sec_735d08c4 marmarek_sec_696e531c marmarek_sec_692db79a marmarek_sec_688f1623 marmarek_sec_201e4cc3 marmarek_sec_160b7a0b marmarek_sec_113cf714 marmarek_sec_109b6fdf marmarek_sec_97f1428a marmarek_sec_93f129d7 marmarek_sec_91c22ed5 marmarek_sec_89af9f06 marmarek_sec_85d18bac marmarek_sec_81ac5fe4 marmarek_sec_77c18513 marmarek_sec_71eeb2ea marmarek_sec_68fa5cee marmarek_sec_66c7326e marmarek_sec_65c0e16e marmarek_sec_64f3338c marmarek_sec_55f7b189 marmarek_sec_55a292c9 marmarek_sec_49cc5d5a marmarek_sec_45f79323 marmarek_sec_41b90963 marmarek_sec_40b3338e marmarek_sec_35d7e6f1 marmarek_sec_33c90326 marmarek_sec_22c5fe0d marmarek_sec_20fc0746 marmarek_sec_16c2b497 marmarek_sec_15ac3d41 marmarek_sec_9ffb5883 marmarek_sec_9f43f503 marmarek_sec_9e64bee1 marmarek_sec_9d85918c marmarek_sec_9d2ab5db marmarek_sec_9ce311f5 marmarek_sec_8db2fb5d marmarek_sec_7f76bce3 marmarek_sec_7cdffb89 marmarek_sec_7bea266a marmarek_sec_7b063902 marmarek_sec_6be15b69 marmarek_sec_5fb232ea marmarek_sec_5f208b29 marmarek_sec_5e61a5a6 marmarek_sec_5ddbd92b marmarek_sec_5c986968 marmarek_sec_5c9616cd marmarek_sec_5c995e08 marmarek_sec_5b6117ae marmarek_sec_4c58f8fb marmarek_sec_4b1d1114
Nothing to show
Find file Copy path
Fetching contributors…
Cannot retrieve contributors at this time
160 lines (121 sloc) 5.62 KB
---===[ 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 [1]:
| 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 [2]:
| 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 [4]:
| 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 [3], 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
===========
[1] https://xenbits.xen.org/xsa/advisory-231.html
[2] https://xenbits.xen.org/xsa/advisory-232.html
[3] https://xenbits.xen.org/xsa/advisory-233.html
[4] https://xenbits.xen.org/xsa/advisory-234.html
--
The Qubes Security Team
https://www.qubes-os.org/security/