-
-
Notifications
You must be signed in to change notification settings - Fork 59
/
qsb-040-2018.txt
142 lines (103 loc) · 5.23 KB
/
qsb-040-2018.txt
1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
27
28
29
30
31
32
33
34
35
36
37
38
39
40
41
42
43
44
45
46
47
48
49
50
51
52
53
54
55
56
57
58
59
60
61
62
63
64
65
66
67
68
69
70
71
72
73
74
75
76
77
78
79
80
81
82
83
84
85
86
87
88
89
90
91
92
93
94
95
96
97
98
99
100
101
102
103
104
105
106
107
108
109
110
111
112
113
114
115
116
117
118
119
120
121
122
123
124
125
126
127
128
129
130
131
132
133
134
135
136
137
138
139
140
141
142
---===[ Qubes Security Bulletin #40 ]===---
2018-05-24
Information leaks due to processor speculative store bypass (XSA-263)
Changelog
==========
2018-05-24: Original QSB published
2018-06-11: Updated and clarified Patching section
Summary
========
On 2018-05-21, the Xen Security Team published Xen Security Advisory
263 (CVE-2018-3639 / XSA-263) [1] with the following description:
| Contemporary high performance processors may use a technique commonly
| known as Memory Disambiguation, whereby speculative execution may
| proceed past unresolved stores. This opens a speculative sidechannel
| in which loads from an address which have had a recent store can
| observe and operate on the older, stale, value.
Please note that this issue was neither predisclosed nor embargoed.
Consequently, the Qubes Security Team has not had time to analyze it in
advance of issuing this bulletin.
Impact
=======
According to XSA-263, the impact of this issue is as follows:
| An attacker who can locate or create a suitable code gadget in a
| different privilege context may be able to infer the content of
| arbitrary memory accessible to that other privilege context.
|
| At the time of writing, there are no known vulnerable gadgets in the
| compiled hypervisor code. Xen has no interfaces which allow JIT code
| to be provided. Therefore we believe that the hypervisor itself is
| not vulnerable. Additionally, we do not think there is a viable
| information leak by one Xen guest against another non-cooperating
| guest.
|
| However, in most configurations, within-guest information leak is
| possible. Mitigation for this generally depends on guest changes
| (for which you must consult your OS vendor) *and* on hypervisor
| support, provided in this advisory.
In light of this, XSA-263 appears to be less severe than the related
Spectre and Meltdown vulnerabilities we discussed in QSB #37 [2].
Patching
=========
The mitigation for this issue is called called "Speculative Store Bypass
Disable" (SSBD). For Intel processors, SSBD requires both a software
update and a CPU microcode update. For AMD processors, a software update
alone is sufficient; no microcode update is necessary. The packages
described below provide the necessary software updates for SSBD. On
2018-05-23, Intel Corporation announced that microcode updates would be
available soon [3]:
| Variant 3a is mitigated in the same processor microcode updates as
| Variant 4, and Intel has released these updates in beta form to OEM
| system manufacturers and system software vendors. They are being
| readied for production release, and will be delivered to consumers
| and IT Professionals in the coming weeks.
However, as of 2018-06-11, we are not aware of any available microcode
updates that address this issue for Intel processors. This bulletin will
be updated once the Intel microcode updates are available.
There are several important things to note about SSBD:
1. On both Intel and AMD processors, SSBD is globally disabled by
default. If the user wishes to enable SSBD globally, the user must do
so manually with the Xen boot option `spec-ctrl=ssbd=true`. However,
enabling this option carries a performance penalty.
2. We concur with the analysis in XSA-263 that this vulnerability
presents minimal risk to Xen itself and minimal risk of inter-guest
attacks. Therefore, we believe that proper compartmentalization is
sufficient for Qubes users to mitigate this issue without having to
enable SSBD globally.
3. For Intel (but not AMD) processors, SSBD can be enabled locally by
Xen guests without the user having to manually enable it globally.
4. For AMD (but not Intel) processors, SSBD cannot be enabled locally by
Xen guests. The user must manually enable it globally for it to have
any effect at all.
5. The guest kernel determines whether SSBD is automatically enabled for
guests on systems with Intel processors. As of 2018-06-11, the
kernels we currently offer in our repositories do not enable SSBD.
The specific packages relevant to this issue are as follows:
For Qubes 3.2:
- Xen packages, version 4.6.6-41
For Qubes 4.0:
- Xen packages, version 4.8.3-8
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 Advisory.
References
===========
[1] https://xenbits.xen.org/xsa/advisory-263.html
[2] https://github.com/QubesOS/qubes-secpack/blob/master/QSBs/qsb-037-2018.txt
[3] https://www.intel.com/content/www/us/en/architecture-and-technology/facts-about-side-channel-analysis-and-intel-products.html
--
The Qubes Security Team
https://www.qubes-os.org/security/