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
177 lines (134 sloc) 7.21 KB
---===[ Qubes Security Bulletin #24 ]===---
July 26, 2016
Critical Xen bug in PV memory virtualization code (XSA 182)
Quick Summary
The Xen Security Team has announced a critical security bug (XSA 182)
in the hypervisor code handling memory virtualization for the PV VMs
| The PV pagetable code has fast-paths for making updates to
| pre-existing pagetable entries, to skip expensive re-validation in
| safe cases (e.g. clearing only Access/Dirty bits). The bits
| considered safe were too broad, and not actually safe.
| A malicious PV guest administrator can escalate their privilege to that
| of the host.
If this sounds familiar to the infamous XSA 148 bug which was
disclosed last year [2], it is because it is indeed a very similar
type of vulnerability, in almost the same piece of Xen hypervisor
code, the code that implements PV memory virtualization. Like XSA 148,
this seems to be a fatal security bug which regrettably affects Qubes
An attacker who exploits this bug can break Qubes-provided isolation.
This means that if an attacker has already exploited another
vulnerability, e.g. in a Web Browser or Networking or USB stack, then
the attacker would be able to compromise the whole Qubes system.
Description and analysis of the bug
The buggy code is present in all mod_l{1..4}_entry() functions, which
are responsible for processing requests from the PV guests to update
their page table mappings. An interested reader is directed to the
original advisory and patch for more details [1].
We have originally concluded that this bug was exploitable in a
relatively simple and reliable way, similarly to what we concluded for
the previously mentioned XSA 148 [2]. Based on this opinion we decided
to treat this as a security critical bug.
But after writing down the draft of this bulletin yesterday, which
included a proposed attack sketch in this section, the other member of
the Qubes Security Team pointed out flaws in the theorized
In response the first person updated her exploitation sketch this
morning. But then further constraints were found (by the second
member) which likely make this second exploitation scenario also
unfeasible. This same person suggested later, however, the original
attack scenario might actually be feasible, pointing to
special-purpose memory structures which might constitute a good
candidate for manipulation thanks to the bug...
Xen's extensive use of constructs such as:
#define l3_disallow_mask(d) (!is_pv_32bit_domain(d) ? \
base_disallow_mask : 0xFFFFF198U)
... make it difficult to reliably reason about validity of certain
invariants, such as whether given flags could, or could not be,
requested by the guest, especially when one considers a full 4-level
hierarchical page-walking code.
In conclusion we have been unable to reach a consensus about practical
exploitability of this bug. In order to be on the safe side, we
decided to continue treating it as critical bug nevertheless. After
all, the bug does violate some fundamental assumptions about
immutability of certain memory mapping structures. The mere fact we
were unable to come up with an agreeable exploitation sketch within
the last 24 hours should not be treated as a mitigation factor. The
rest of this bulletin is written with an assumption the bug is
critical indeed.
Admittedly a reasonable thing for us to have done would be to attempt
to write an actual proof-of-concept exploit and see if it worked.
However, because of the unfortunate timing of when it was realized
that exploitation might be more tricky than we thought (i.e.
yesterday evening), we have not been able to work on an exploit.
Thoughts about Xen security
This bug, being the second critical bug in the Xen PV virtualization
code publicly discussed in a relatively short period of time, cannot
simply be shrugged off, patched, and forgotten. It begs for answers to
critical questions, such as: 1) has Xen been written by competent
developers? 2) how many more bugs of this caliber are we going to
witness in the future? 3) what can or should we do to protect against
such gaping holes?
An observant reader will be quick to point out that it may have been a
mistake for Qubes to embrace paravirtualization (PV) as the default
mode of isolation. Indeed, both the bug we're discussing today, as
well as the previously mentioned XSA 148, both present a
hard-to-ignore argument that PV might be too complex of a technology
for security-critical applications.
But years ago, when we were designing Qubes OS, we believed PV offered
an edge over full virtualization (HVM) because it didn't require
Shadow Page Tables handling code, an arguably even more complex
approach to memory virtualization. But as nearly all recent processors
support so-called Second Level Address Translation (SLAT), or Intel
EPT, this argument has lost its merit. SLAT (EPT) is an extension to
Intel VT-x virtualization, which originally was capable of only CPU
virtualization but not memory virtualization.
Consequently, we have decided to move to hardware memory
virtualization for the upcoming Qubes 4.0 release [4]. We believe this
is the best _generic_ solution we can afford to implement in the near
future (in addition to patching this very bug, of course).
A more radical reader might be of the opinion that we should
completely replace Xen with some other hypervisor. Such an opinion is
surely not unfounded, as we have previously expressed our
disappointment in the Xen security process [5]. Sadly, not much has
improved over the past several months. Moreover, even though Qubes is
now based on a hypervisor-abstracting architecture ("Odyssey"), which
should make switching to a different VMM a relatively easy task, the
primary problem that remains is the lack of a good alternative
hypervisor to which we could move [6].
As an exceptional measure, given the significance of this bug, we have
uploaded the patched packages directly to the current repository,
bypassing the usual one-week waiting period during which new packages
normally reside in the security-testing repository.
The specific packages that resolve the problem discussed in this
bulletin have been uploaded to the current repositories for all
supported Qubes OS versions.
Qubes OS 3.0:
- Multiple Xen packages, version 4.4.3-12
Qubes OS 3.1 and 3.2:
- Multiple Xen packages, version 4.6.1-20
The packages can be installed in dom0 via the qubes-dom0-update command
or via the Qubes VM Manager.
This bug has been made available to us by the Xen Security Team via
the Xen pre-disclosure list [1]. Please see the original announcement
for any credits.
The Qubes Security Team