QSB #33: Xen hypervisor (XSA-231 through XSA-234)
163 views
Skip to first unread message
Andrew David Wong
Sep 12, 2017, 10:12:40 AM9/12/17
to qubes-a...@googlegroups.com, qubes...@googlegroups.com, qubes...@googlegroups.com
-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA512
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:
<https://github.com/QubesOS/qubes-secpack/blob/master/QSBs/qsb-033-2017.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-231 through XSA-234 in the XSA Tracker:
<https://www.qubes-os.org/security/xsa/>
```
---===[ 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/
```
- --
Andrew David Wong (Axon)
Community Manager, Qubes OS
https://www.qubes-os.org
-----BEGIN PGP SIGNATURE-----
iQIcBAEBCgAGBQJZt+s/AAoJENtN07w5UDAwK9wP/1tJm9NDcwYk2gZeeTa5Mi8R
t9m8uQ8RDzFM+eeyMRsY4vscYUoHMpXclgek5trmlP3KYwSo20k/tJqY8lvA0IaY
RwaEohBo7tyhWAUV6cIU6JWN5c3e/4QXQK9mohyqlN+GK1MpD2i3m2xljI0O3t7+
z9OLcmCldpkC8KdBhwJ9M1iqmOEdUHHBLKtzWk39doNnt539yfw6XhnCAbyVh6Sm
slFaFc2l9jI6tPEF6OGKJh76SsMGEQBxUfE04rRLDSSaFcqcxfRV/wgPoUB5pb92
1u9+zsbqm4WMxxGjyLfaU/eCQ0+M/RyM1EBnWFyC1gulKgU7QtAymMQfoDveeZlU
xEIyg3kPVNwdjs+luqhpSkok+HL3zjcI+ulE1C135G/iChwlwAl9INkb4e3sgQzf
/9BOFiLMG4lRUF6n0Rvu5dUgKclekgz3YVCl17IMnkJWE2iRweQSYXp2tHKnW+Y3
CZlyS6nOTQvpZbP+A+QmqEh9aSHQRmWfC2JLR8c5rGMV2cDNg17NnlY+eBtVyzfi
qhEdGy+e0WVeNwgljrApzTYbh3RG7dEyJbIgQ765+qhCyT5r2LsmOY6K8H8emibc
r07OD//v8SXer4TEis/WoQOCqgYvXM+165HXCw2aF4/9IyAId2RUDFtmW4TcbrFq
omPnK4+xkfX0kHLt942U
=zfZT
-----END PGP SIGNATURE-----
Hash: SHA512
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:
<https://github.com/QubesOS/qubes-secpack/blob/master/QSBs/qsb-033-2017.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-231 through XSA-234 in the XSA Tracker:
<https://www.qubes-os.org/security/xsa/>
```
---===[ 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/
```
- --
Andrew David Wong (Axon)
Community Manager, Qubes OS
https://www.qubes-os.org
-----BEGIN PGP SIGNATURE-----
iQIcBAEBCgAGBQJZt+s/AAoJENtN07w5UDAwK9wP/1tJm9NDcwYk2gZeeTa5Mi8R
t9m8uQ8RDzFM+eeyMRsY4vscYUoHMpXclgek5trmlP3KYwSo20k/tJqY8lvA0IaY
RwaEohBo7tyhWAUV6cIU6JWN5c3e/4QXQK9mohyqlN+GK1MpD2i3m2xljI0O3t7+
z9OLcmCldpkC8KdBhwJ9M1iqmOEdUHHBLKtzWk39doNnt539yfw6XhnCAbyVh6Sm
slFaFc2l9jI6tPEF6OGKJh76SsMGEQBxUfE04rRLDSSaFcqcxfRV/wgPoUB5pb92
1u9+zsbqm4WMxxGjyLfaU/eCQ0+M/RyM1EBnWFyC1gulKgU7QtAymMQfoDveeZlU
xEIyg3kPVNwdjs+luqhpSkok+HL3zjcI+ulE1C135G/iChwlwAl9INkb4e3sgQzf
/9BOFiLMG4lRUF6n0Rvu5dUgKclekgz3YVCl17IMnkJWE2iRweQSYXp2tHKnW+Y3
CZlyS6nOTQvpZbP+A+QmqEh9aSHQRmWfC2JLR8c5rGMV2cDNg17NnlY+eBtVyzfi
qhEdGy+e0WVeNwgljrApzTYbh3RG7dEyJbIgQ765+qhCyT5r2LsmOY6K8H8emibc
r07OD//v8SXer4TEis/WoQOCqgYvXM+165HXCw2aF4/9IyAId2RUDFtmW4TcbrFq
omPnK4+xkfX0kHLt942U
=zfZT
-----END PGP SIGNATURE-----
Lorenzo Lamas
Sep 12, 2017, 1:52:14 PM9/12/17
to qubes-users
Is it necessary to install corresponding Xen packages in TemplateVM's from the security-testing repository for VM's?
yreb-qusw
Sep 12, 2017, 4:24:52 PM9/12/17
to qubes...@googlegroups.com, qubes-a...@googlegroups.com, qubes...@googlegroups.com
maybe could consider removing
"Occasionally fuckups happen," ......unless one is going for the
unprofesional vulgarity crowd IMHO
2cents ,
"Occasionally fuckups happen," ......unless one is going for the
unprofesional vulgarity crowd IMHO
2cents ,
qubester
Sep 12, 2017, 4:32:04 PM9/12/17
to qubes-users
------
1)
So, for discussion do most folks "patch immediately" or "wait for
stable" ??
2)
Guess, I need to start studying the PBRM(above) as I imagine I'll
be on 3.2 for some time, maybe till it's no longer updated if there
is going to be NO GUI VM Manager ever ??
michael-q
Sep 13, 2017, 5:13:39 PM9/13/17
to qubes-users
yre...@riseup.net
Sep 19, 2017, 9:47:49 PM9/19/17
to qubes...@googlegroups.com
every fedora25 template update fails ** is this NOW expected behavior?
it fails unless I reboot, after I've done even 1 suspend
really a big pita, as there are so many silly emacs updates, and libthis
and libthat constantly going on, I'm going to have to just ignore
the offer to update for weeks .....if this is really the new norm, it
had worked fine before.
something to do with my repository cache, when it does spit out an
explanation ...
it fails unless I reboot, after I've done even 1 suspend
really a big pita, as there are so many silly emacs updates, and libthis
and libthat constantly going on, I'm going to have to just ignore
the offer to update for weeks .....if this is really the new norm, it
had worked fine before.
something to do with my repository cache, when it does spit out an
explanation ...
cooloutac
Sep 20, 2017, 8:13:36 AM9/20/17
to qubes-users
I always enable security testing. I'll be staying on 3.2 too for a while for same reasons. Will try out 4.0 on final release, hopefully my family can still use it.
cooloutac
Sep 20, 2017, 8:13:50 AM9/20/17
to qubes-users
definitely not expected behavior. Have you tried cleaning the cache. or just deleting the template and installing another one?
none
Sep 20, 2017, 3:25:23 PM9/20/17
to qubes-users
On 09/20/2017 02:13 AM, cooloutac wrote:
--
So if dnf clean all did not clean it up, then it's not part of the dnf
cache. The dnf cache lives in /var/cache/dnf; /var/cache/yum may be
leftover from a previous version of Fedora (prior to the upgrade from
yum to dnf), and you can almost certainly remove the files in that
directory safely.
--
I tried all the dnf clean all, etc, 0 files removed, but I don't know
which files to remove from /var/cache/yum or /var/cache/dnf
there are various .solvx files and dir's and something called :
-rw-r--r-- 1 root root 2 Sep 19 15:38 expired_repos.json
but I hesitate to do anything manually ; hmm del the template I guess
is what is left ....
> On Tuesday, September 19, 2017 at 9:47:49 PM UTC-4, yre...-sGOZH3hwPm2sTnJN9+BGXg@public.gmane.org wrote:
>> every fedora25 template update fails ** is this NOW expected behavior?
>>
>> it fails unless I reboot, after I've done even 1 suspend
>>
>> really a big pita, as there are so many silly emacs updates, and libthis
>> and libthat constantly going on, I'm going to have to just ignore
>> the offer to update for weeks .....if this is really the new norm, it
>> had worked fine before.
>>
>> something to do with my repository cache, when it does spit out an
>> explanation ...
>
> definitely not expected behavior. Have you tried cleaning the cache. or just deleting the template and installing another one?
>
I found online this :
>> every fedora25 template update fails ** is this NOW expected behavior?
>>
>> it fails unless I reboot, after I've done even 1 suspend
>>
>> really a big pita, as there are so many silly emacs updates, and libthis
>> and libthat constantly going on, I'm going to have to just ignore
>> the offer to update for weeks .....if this is really the new norm, it
>> had worked fine before.
>>
>> something to do with my repository cache, when it does spit out an
>> explanation ...
>
> definitely not expected behavior. Have you tried cleaning the cache. or just deleting the template and installing another one?
>
--
So if dnf clean all did not clean it up, then it's not part of the dnf
cache. The dnf cache lives in /var/cache/dnf; /var/cache/yum may be
leftover from a previous version of Fedora (prior to the upgrade from
yum to dnf), and you can almost certainly remove the files in that
directory safely.
--
I tried all the dnf clean all, etc, 0 files removed, but I don't know
which files to remove from /var/cache/yum or /var/cache/dnf
there are various .solvx files and dir's and something called :
-rw-r--r-- 1 root root 2 Sep 19 15:38 expired_repos.json
but I hesitate to do anything manually ; hmm del the template I guess
is what is left ....
Reply all
Reply to author
Forward
0 new messages