In “Following the White Rabbit: Software attacks against Intel(R) VT-d technology” (https://invisiblethingslab.com/resources/2011/Software%20Attacks%20on%20Intel%20VT-d.pdf), Rafał Wojtczuk and Joanna Rutkowska describe an attack against VT-d on machines without interrupt remapping support.
For our purposes, the result they describe on page 8 is very important:
Even without access to the PCI config space, a malicious guest is, in many cases, able to generate arbitrary MSIs.
So long as writing to the MSI enable flag does not have any unrelated side effects, there’s no obvious way in which allowing it can worsen security, since an attacker who can set it can already generate arbitrary MSIs anyway.
Meanwhile, we reap the benefits of using HVMs to better isolate VMs with attached PCI devices.
So, we decided to implement option (2).
Based on the analysis above, one could argue that we might as well allow writes to the enable flags for all VMs with attached PCI devices, since doing so shouldn’t decrease security.
To be extra cautious, however, we only allow writes to the enable flags for stub domains.
In other cases, it’s not necessary.
(Here are our patches for pciback (https://github.com/QubesOS/qubes-linux-kernel/pull/12/commits/96b956b38cb24230848a563d3e1ce359c8d8db66) and libxl (https://github.com/QubesOS/qubes-vmm-xen/pull/15/commits/55ef595451d9e2e5583a31c4a3600507ae5500f7).)
Now, the previously problematic devices function correctly inside HVMs.
(Here are the full pull requests: 1 (https://github.com/QubesOS/qubes-linux-kernel/pull/12), 2 (https://github.com/QubesOS/qubes-vmm-xen/pull/15), 3 (https://github.com/QubesOS/qubes-vmm-xen-stubdom-linux/pull/3).)
We just merged this feature, and it will be included in Qubes 4.0-rc2, which we plan to release next week.
After these patches undergo further testing, we plan to upstream them so that all Xen users can benefit from our work.
If you have any questions or comments, please write to us on qubes-devel (https://www.qubes-os.org/mailing-lists/#qubes-devel).
*We’ve switch from the Mini-OS-based stub domain to a Linux-based stub domain in Qubes 4.0 based on patches (https://lists.xenproject.org/archives/html/xen-devel/2015-02/msg00426.html) from Anthony Perad and Eric Shelton.
The switch is not significant for the purposes of this article.
For our purposes, the result they describe on page 8 is very important:
Even without access to the PCI config space, a malicious guest is, in many cases, able to generate arbitrary MSIs.
So long as writing to the MSI enable flag does not have any unrelated side effects, there’s no obvious way in which allowing it can worsen security, since an attacker who can set it can already generate arbitrary MSIs anyway.
Meanwhile, we reap the benefits of using HVMs to better isolate VMs with attached PCI devices.
So, we decided to implement option (2).
Based on the analysis above, one could argue that we might as well allow writes to the enable flags for all VMs with attached PCI devices, since doing so shouldn’t decrease security.
To be extra cautious, however, we only allow writes to the enable flags for stub domains.
In other cases, it’s not necessary.
(Here are our patches for pciback (https://github.com/QubesOS/qubes-linux-kernel/pull/12/commits/96b956b38cb24230848a563d3e1ce359c8d8db66) and libxl (https://github.com/QubesOS/qubes-vmm-xen/pull/15/commits/55ef595451d9e2e5583a31c4a3600507ae5500f7).)
Now, the previously problematic devices function correctly inside HVMs.
(Here are the full pull requests: 1 (https://github.com/QubesOS/qubes-linux-kernel/pull/12), 2 (https://github.com/QubesOS/qubes-vmm-xen/pull/15), 3 (https://github.com/QubesOS/qubes-vmm-xen-stubdom-linux/pull/3).)
We just merged this feature, and it will be included in Qubes 4.0-rc2, which we plan to release next week.
After these patches undergo further testing, we plan to upstream them so that all Xen users can benefit from our work.
If you have any questions or comments, please write to us on qubes-devel (https://www.qubes-os.org/mailing-lists/#qubes-devel).
*We’ve switch from the Mini-OS-based stub domain to a Linux-based stub domain in Qubes 4.0 based on patches (https://lists.xenproject.org/archives/html/xen-devel/2015-02/msg00426.html) from Anthony Perad and Eric Shelton.
The switch is not significant for the purposes of this article.
New article by Qubes team member Simon Gaiser (HW42): "MSI support for PCI device pass-through with stub domains"
https://t.co/eDVzduPoWY
https://t.co/eDVzduPoWY
Qubes OS
MSI support for PCI device pass-through with stub domains
Introduction In this post, we will describe how we fixed MSI support for VMs running in HVM mode in Qubes 4.0. First, allow us to provide some background about the MSI feature and why we need it i...
Announcing the Xen Project 4.10 RC and Test Day Schedules
https://blog.xenproject.org/2017/10/19/announcing-the-xen-project-4-10-rc-and-test-day-schedules/
On Monday, we created Xen 4.10 RC1 and will release a new release candidate every MONDAY, until we declare a release candidate as the final candidate and cut the Xen 4.10 release. We will also hold a Test Day every WEDNESDAY for the release candidate that was released the week prior to the Test Day […]
https://blog.xenproject.org/2017/10/19/announcing-the-xen-project-4-10-rc-and-test-day-schedules/
On Monday, we created Xen 4.10 RC1 and will release a new release candidate every MONDAY, until we declare a release candidate as the final candidate and cut the Xen 4.10 release. We will also hold a Test Day every WEDNESDAY for the release candidate that was released the week prior to the Test Day […]
Qubes OS 4.0-rc2 has been released!
https://www.qubes-os.org/news/2017/10/23/qubes-40-rc2/
We’re pleased to announce the second release candidate for Qubes 4.0! As usual,
this release candidate includes numerous bug fixes over the
previous one (https://www.qubes-os.org/news/2017/07/31/qubes-40-rc1/).
Two of the most important changes are:
Improved PCI passthrough (https://www.qubes-os.org/news/2017/10/18/msi-support/) with sys-net and sys-usb running in
HVM mode by default. With this change, we’ve officially achieved our
Qubes 4.0 goal (https://www.qubes-os.org/news/2016/07/21/new-hw-certification-for-q4/) of having all qubes running in HVM mode by
default for enhanced security.
Whonix templates are back! We’ve fixed various (https://phabricator.whonix.org/T697)
blocking (https://phabricator.whonix.org/T710) issues (https://phabricator.whonix.org/T491), and the Whonix templates are
available in the default installer once again. We’re even debuting new
Whonix-based DispVMs!
There were two primary reasons for the substantial delay (https://www.qubes-os.org/doc/releases/4.0/schedule/) of this
release. The first was our discovery of the security issue (https://github.com/QubesOS/qubes-secpack/blob/master/QSBs/qsb-034-2017.txt) that would
come to be known as XSA-237 (https://xenbits.xen.org/xsa/advisory-237.html). As part of our coordination with the Xen Project
Security Team, we had to wait through the embargo period until XSA-237 was
publicly released before integrating various PCI passthrough fixes.
The second reason for the delay was the last-minute discovery of a bug related
to resizing the root filesystem of a qube. We faced a choice (https://groups.google.com/d/msgid/qubes-devel/20171013222228.GF10749%40mail-itl)
between (1) keeping the partition layout the same at the cost of increasing
maintenance complexity in the future or (2) changing the partition layout to
simplify the code at the cost of rebuilding all the templates and delaying the
release. We chose (https://groups.google.com/d/msgid/qubes-devel/20171016134524.GI1059%40mail-itl) the second option, which resulted in an
additional one week delay, but we’re confident that this is the most prudent
move in the long run.
As a consequence of the partition layout change, it will be necessary for
current 4.0-rc1 testers to perform a clean reinstall of 4.0-rc2 rather than
attempting to upgrade in-place. We sincerely apologize for this inconvenience.
Our growing community has been putting in a lot of hard work testing the first
4.0 release candidate and submitting bug reports, and we greatly appreciate your
effort. From the whole Qubes team, thank you! Your feedback helps us make the
final release as stable as possible. Please keep up the great work!
Further details, including full installation and update instructions,
are available in the Qubes 4.0 release notes (https://www.qubes-os.org/doc/releases/4.0/release-notes/). The new
installation image is available on the Downloads (https://www.qubes-os.org/downloads/) page.
https://www.qubes-os.org/news/2017/10/23/qubes-40-rc2/
We’re pleased to announce the second release candidate for Qubes 4.0! As usual,
this release candidate includes numerous bug fixes over the
previous one (https://www.qubes-os.org/news/2017/07/31/qubes-40-rc1/).
Two of the most important changes are:
Improved PCI passthrough (https://www.qubes-os.org/news/2017/10/18/msi-support/) with sys-net and sys-usb running in
HVM mode by default. With this change, we’ve officially achieved our
Qubes 4.0 goal (https://www.qubes-os.org/news/2016/07/21/new-hw-certification-for-q4/) of having all qubes running in HVM mode by
default for enhanced security.
Whonix templates are back! We’ve fixed various (https://phabricator.whonix.org/T697)
blocking (https://phabricator.whonix.org/T710) issues (https://phabricator.whonix.org/T491), and the Whonix templates are
available in the default installer once again. We’re even debuting new
Whonix-based DispVMs!
There were two primary reasons for the substantial delay (https://www.qubes-os.org/doc/releases/4.0/schedule/) of this
release. The first was our discovery of the security issue (https://github.com/QubesOS/qubes-secpack/blob/master/QSBs/qsb-034-2017.txt) that would
come to be known as XSA-237 (https://xenbits.xen.org/xsa/advisory-237.html). As part of our coordination with the Xen Project
Security Team, we had to wait through the embargo period until XSA-237 was
publicly released before integrating various PCI passthrough fixes.
The second reason for the delay was the last-minute discovery of a bug related
to resizing the root filesystem of a qube. We faced a choice (https://groups.google.com/d/msgid/qubes-devel/20171013222228.GF10749%40mail-itl)
between (1) keeping the partition layout the same at the cost of increasing
maintenance complexity in the future or (2) changing the partition layout to
simplify the code at the cost of rebuilding all the templates and delaying the
release. We chose (https://groups.google.com/d/msgid/qubes-devel/20171016134524.GI1059%40mail-itl) the second option, which resulted in an
additional one week delay, but we’re confident that this is the most prudent
move in the long run.
As a consequence of the partition layout change, it will be necessary for
current 4.0-rc1 testers to perform a clean reinstall of 4.0-rc2 rather than
attempting to upgrade in-place. We sincerely apologize for this inconvenience.
Our growing community has been putting in a lot of hard work testing the first
4.0 release candidate and submitting bug reports, and we greatly appreciate your
effort. From the whole Qubes team, thank you! Your feedback helps us make the
final release as stable as possible. Please keep up the great work!
Further details, including full installation and update instructions,
are available in the Qubes 4.0 release notes (https://www.qubes-os.org/doc/releases/4.0/release-notes/). The new
installation image is available on the Downloads (https://www.qubes-os.org/downloads/) page.
RT @josephfcox: Qubes releases version 4.0-rc2. Includes disposable Whonix VMs; for when you want to be anonymous and ephemeral https://t.co/Q8jJqoCjC5 https://t.co/7avM2L0l2i
Qubes OS
Qubes OS 4.0-rc2 has been released!
We’re pleased to announce the second release candidate for Qubes 4.0! As usual, this release candidate includes numerous bug fixes over the previous one. Two of the most important changes are: ...
Qubes Security Bulletin #35:
Xen hypervisor issue related to grant tables (XSA-236)
https://t.co/dY3o3KmPCo
Xen hypervisor issue related to grant tables (XSA-236)
https://t.co/dY3o3KmPCo
GitHub
QubesOS/qubes-secpack
qubes-secpack - Qubes Security Pack
QSB #35: Xen hypervisor issue related to grant tables (XSA-236)
https://www.qubes-os.org/news/2017/10/25/qsb-35/
Dear Qubes Community,
We have published Qubes Security Bulletin (QSB) #35:
Xen hypervisor issue related to grant tables (XSA-236).
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 #35 in the qubes-secpack:
https://github.com/QubesOS/qubes-secpack/blob/master/QSBs/qsb-035-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-236 in the XSA Tracker:
https://www.qubes-os.org/security/xsa/#236
---===[ Qubes Security Bulletin #35 ]===---
October 24, 2017
Xen hypervisor issue related to grant tables (XSA-236)
Summary
========
The Xen Security Team has published Xen Security Advisory 236, which
concerns an issue with the grant tables mechanism used to share memory
between domains. The practical impact of this advisory is believed to
be denial of service only. However, privilege escalation and information
leaks are theoretically possible.
Technical details
==================
Xen Security Advisory 236 [1]:
| Grant copying code made an implication that any grant pin would be
| accompanied by a suitable page reference. Other portions of code,
| however, did not match up with that assumption. When such a grant
| copy operation is being done on a grant of a dying domain, the
| assumption turns out wrong.
|
| A malicious guest administrator can cause hypervisor memory
| corruption, most likely resulting in host crash and a Denial of
| Service. Privilege escalation and information leaks cannot be ruled
| out.
Compromise Recovery
====================
Beginning 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. If you believe your system may be
compromised (perhaps because of the issue discussed in this bulletin),
please 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 problem discussed in this
bulletin are as follows:
For Qubes 3.2:
- Xen packages, version 4.6.6-34
For Qubes 4.0:
- Xen packages, version 4.8.2-9
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-236.html
--
The Qubes Security Team
https://www.qubes-os.org/security/
https://www.qubes-os.org/news/2017/10/25/qsb-35/
Dear Qubes Community,
We have published Qubes Security Bulletin (QSB) #35:
Xen hypervisor issue related to grant tables (XSA-236).
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 #35 in the qubes-secpack:
https://github.com/QubesOS/qubes-secpack/blob/master/QSBs/qsb-035-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-236 in the XSA Tracker:
https://www.qubes-os.org/security/xsa/#236
---===[ Qubes Security Bulletin #35 ]===---
October 24, 2017
Xen hypervisor issue related to grant tables (XSA-236)
Summary
========
The Xen Security Team has published Xen Security Advisory 236, which
concerns an issue with the grant tables mechanism used to share memory
between domains. The practical impact of this advisory is believed to
be denial of service only. However, privilege escalation and information
leaks are theoretically possible.
Technical details
==================
Xen Security Advisory 236 [1]:
| Grant copying code made an implication that any grant pin would be
| accompanied by a suitable page reference. Other portions of code,
| however, did not match up with that assumption. When such a grant
| copy operation is being done on a grant of a dying domain, the
| assumption turns out wrong.
|
| A malicious guest administrator can cause hypervisor memory
| corruption, most likely resulting in host crash and a Denial of
| Service. Privilege escalation and information leaks cannot be ruled
| out.
Compromise Recovery
====================
Beginning 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. If you believe your system may be
compromised (perhaps because of the issue discussed in this bulletin),
please 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 problem discussed in this
bulletin are as follows:
For Qubes 3.2:
- Xen packages, version 4.6.6-34
For Qubes 4.0:
- Xen packages, version 4.8.2-9
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-236.html
--
The Qubes Security Team
https://www.qubes-os.org/security/
RT @okayultra: LOL, @QubesOS and its painful-but-necessary clipboard isolation has prevented literally hundreds such incidents for me. https://t.co/aLNP9vXJ8X
Twitter
Adrienne Porter Felt
Ummmmmm I accidentally emailed this comic to several contractors instead of our building plans
Thank you Peter for you continued support! https://t.co/hLdDqAUZej
Twitter
Peter Todd
Donated a % of my consulting company's last year revenue to @QubesOS I rely on it for all my work, and recommend it to clients too.
Forwarded from Qubes OS
Join the group!
Rules:
>No spam/ads/NSFW/shit posts
>Keep media like/stickers to a minimum.
>Respect others
>Use common sense
>Stay on topic
If you need help please ask!
Rules are enforced with ban or restrictions.
Link:
t.me/joinchat/B8FHpkEToMeDRgQ_cI60XQ
Rules:
>No spam/ads/NSFW/shit posts
>Keep media like/stickers to a minimum.
>Respect others
>Use common sense
>Stay on topic
If you need help please ask!
Rules are enforced with ban or restrictions.
Link:
t.me/joinchat/B8FHpkEToMeDRgQ_cI60XQ
RT @B_Meson: @micahflee correct me if I’m wrong but also won’t effect you if you use Qubes with a Whonix VM https://t.co/K43SHLOMlM
Twitter
Ars Technica
Critical Tor flaw leaks users’ real IP address—update now https://t.co/SmwqDmywV3 by @dangoodin001
RT @ttaskett: Another reason to run @QubesOS: Linux vulnerable to USB devices. #badusb #infosec
https://t.co/u56UAAbAzw
https://t.co/u56UAAbAzw
BleepingComputer
Linux Has a USB Driver Security Problem
USB drivers included in the Linux kernel are rife with security flaws that in some cases can be exploited to run untrusted code and take over users' computers.
RT @rootkovska: Nobody! The whole point of @QubesOS is that we don't need to trust the USB drivers :)
#SecurityThroughDistrusting https://t.co/xOJP6vK0ZP
#SecurityThroughDistrusting https://t.co/xOJP6vK0ZP
Twitter
Worship The Fallen
@ttaskett @QubesOS Which USB drivers is @QubesOS using? Who audited them?
Xen Project Membership Spotlight: Citrix
https://blog.xenproject.org/2017/11/21/xen-project-membership-spotlight-citrix/
The Xen Project is comprised of a diverse set of member companies and contributors that are committed to the growth and success of the Xen Project Hypervisor. The Xen Project Hypervisor is a staple technology for server and cloud vendors, and is gaining traction in the embedded, security and automotive space. This blog series highlights […]
https://blog.xenproject.org/2017/11/21/xen-project-membership-spotlight-citrix/
The Xen Project is comprised of a diverse set of member companies and contributors that are committed to the growth and success of the Xen Project Hypervisor. The Xen Project Hypervisor is a staple technology for server and cloud vendors, and is gaining traction in the embedded, security and automotive space. This blog series highlights […]
Comment on What’s New in the Xen Project Hypervisor 4.9? by hopperyelena
https://blog.xenproject.org/2017/06/28/whats-new-in-the-xen-project-hypervisor-4-9/#comment-408
I Have the same question..
https://blog.xenproject.org/2017/06/28/whats-new-in-the-xen-project-hypervisor-4-9/#comment-408
I Have the same question..
Xen Project 4.7.4 and 4.9.1 are available
https://blog.xenproject.org/2017/11/27/xen-project-4-7-4-and-4-9-1-are-available/
I am pleased to announce the release of Xen 4.7.4 and 4.9.1. Xen Project Maintenance releases are released in line with our Maintenance Release Policy. We recommend that all users of the 4.7 and 4.9 stable series update to the latest point release. These releases are available from their git repositories xenbits.xen.org/gitweb/?p=xen.git;a=shortlog;h=refs/heads/stable-4.7 (tag RELEASE-4.7.4) xenbits.xen.org/gitweb/?p=xen.git;a=shortlog;h=refs/heads/stable-4.9 […]
https://blog.xenproject.org/2017/11/27/xen-project-4-7-4-and-4-9-1-are-available/
I am pleased to announce the release of Xen 4.7.4 and 4.9.1. Xen Project Maintenance releases are released in line with our Maintenance Release Policy. We recommend that all users of the 4.7 and 4.9 stable series update to the latest point release. These releases are available from their git repositories xenbits.xen.org/gitweb/?p=xen.git;a=shortlog;h=refs/heads/stable-4.7 (tag RELEASE-4.7.4) xenbits.xen.org/gitweb/?p=xen.git;a=shortlog;h=refs/heads/stable-4.9 […]
Qubes OS 4.0-rc3 has been released!
https://www.qubes-os.org/news/2017/11/27/qubes-40-rc3/
We’re pleased to announce the third release candidate for Qubes 4.0! Our
goal for this release candidate is to improve the stability and
reliability of Qubes 4.0, so we’ve prioritized fixing known bugs over
introducing new features. Many of the bugs discovered in our previous
release candidate (https://www.qubes-os.org/news/2017/10/23/qubes-40-rc2/) are now resolved. A full list of
the Qubes 4.0 issues closed so far is available here (https://github.com/QubesOS/qubes-issues/issues?q=is%3Aissue+milestone%3A%22Release+4.0%22+is%3Aclosed).
As always, we’re immensely grateful to our community of testers for
taking the time to discover and report bugs (https://www.qubes-os.org/doc/reporting-bugs/). Thanks to your efforts,
we’re able to fix these bugs before the final release of Qubes 4.0. We
encourage you to continue diligently testing this third release
candidate so that we can work together to improve Qubes 4.0 before the
stable release.
Current users of Qubes 4.0-rc2 can upgrade in-place by downloading the
latest updates from the testing repositories in both
dom0 (https://www.qubes-os.org/doc/software-update-dom0/#testing-repositories) and TemplateVMs (https://www.qubes-os.org/doc/software-update-vm/#testing-repositories). Further details,
including full installation instructions, are available in the Qubes
4.0 release notes (https://www.qubes-os.org/doc/releases/4.0/release-notes/). The new installation image is
available on the Downloads (https://www.qubes-os.org/downloads/) page.
https://www.qubes-os.org/news/2017/11/27/qubes-40-rc3/
We’re pleased to announce the third release candidate for Qubes 4.0! Our
goal for this release candidate is to improve the stability and
reliability of Qubes 4.0, so we’ve prioritized fixing known bugs over
introducing new features. Many of the bugs discovered in our previous
release candidate (https://www.qubes-os.org/news/2017/10/23/qubes-40-rc2/) are now resolved. A full list of
the Qubes 4.0 issues closed so far is available here (https://github.com/QubesOS/qubes-issues/issues?q=is%3Aissue+milestone%3A%22Release+4.0%22+is%3Aclosed).
As always, we’re immensely grateful to our community of testers for
taking the time to discover and report bugs (https://www.qubes-os.org/doc/reporting-bugs/). Thanks to your efforts,
we’re able to fix these bugs before the final release of Qubes 4.0. We
encourage you to continue diligently testing this third release
candidate so that we can work together to improve Qubes 4.0 before the
stable release.
Current users of Qubes 4.0-rc2 can upgrade in-place by downloading the
latest updates from the testing repositories in both
dom0 (https://www.qubes-os.org/doc/software-update-dom0/#testing-repositories) and TemplateVMs (https://www.qubes-os.org/doc/software-update-vm/#testing-repositories). Further details,
including full installation instructions, are available in the Qubes
4.0 release notes (https://www.qubes-os.org/doc/releases/4.0/release-notes/). The new installation image is
available on the Downloads (https://www.qubes-os.org/downloads/) page.
QSB #36: Xen hypervisor issue in populate-on-demand code (XSA-247)
https://www.qubes-os.org/news/2017/11/28/qsb-36/
Dear Qubes Community,
We have just published Qubes Security Bulletin (QSB) #36:
Xen hypervisor issue in populate-on-demand code (XSA-247).
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 #36 in the qubes-secpack:
https://github.com/QubesOS/qubes-secpack/blob/master/QSBs/qsb-036-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-247 in the XSA Tracker:
https://www.qubes-os.org/security/xsa/#247
---===[ Qubes Security Bulletin #36 ]===---
November 28, 2017
Xen hypervisor issue in populate-on-demand code (XSA-247)
Summary
========
The Xen Security Team has published Xen Security Advisory 247, which
concerns an issue with the populate-on-demand mechanism used to overbook
memory. We believe it would be very difficult, in practice, to exploit
this issue for privilege escalation.
Additionally, the Xen Security Team has published Xen Security
Advisory 246 (x86: infinite loop due to missing PoD error checking),
with the impact being denial of service only.
Technical details
==================
Xen Security Advisory 247 [1]:
| Certain actions require modification of entries in a guest's P2M
| (Physical-to-Machine) table. When large pages are in use for this
| table, such an operation may incur a memory allocation (to replace a
| large mapping with individual smaller ones). If this allocation
| fails, the p2m_set_entry() function will return an error.
|
| Unfortunately, several places in the populate-on-demand code don't
| check the return value of p2m_set_entry() to see if it succeeded.
|
| In some cases, the operation was meant to remove an entry from the p2m
| table. If this removal fails, a malicious guest may engineer that the
| page be returned to the Xen free list, making it available to be
| allocated to another domain, while it retains a writable mapping to
| the page.
|
| In other cases, the operation was meant to remove special
| populate-on-demand entries; if this removal fails, the internal
| accounting becomes inconsistent and may eventually hit a BUG().
|
| The allocation involved comes from a separate pool of memory created
| when the domain is created; under normal operating conditions it never
| fails, but a malicious guest may be able to engineer situations where
| this pool is exhausted.
|
| An unprivileged guest can retain a writable mapping of freed memory.
| Depending on how this page is used, it could result in either an
| information leak, or full privilege escalation.
|
| Alternatively, an unprivileged guest can cause Xen to hit a BUG(),
| causing a clean crash - ie, host-wide denial-of-service (DoS).
Xen Security Advisory 246 [2]:
| Failure to recognize errors being returned from low level functions in
| Populate on Demand (PoD) code may result in higher level code entering
| an infinite loop.
|
| A malicious HVM guest can cause one pcpu to permanently hang. This
| normally cascades into the whole system freezing, resulting in a a
| host Denial of Service (DoS).
Compromise Recovery
====================
Beginning 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. If you believe your system may be
compromised (perhaps because of the issue discussed in this bulletin),
please 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 problem discussed in this
bulletin are as follows:
For Qubes 3.2:
- Xen packages, version 4.6.6-35
https://www.qubes-os.org/news/2017/11/28/qsb-36/
Dear Qubes Community,
We have just published Qubes Security Bulletin (QSB) #36:
Xen hypervisor issue in populate-on-demand code (XSA-247).
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 #36 in the qubes-secpack:
https://github.com/QubesOS/qubes-secpack/blob/master/QSBs/qsb-036-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-247 in the XSA Tracker:
https://www.qubes-os.org/security/xsa/#247
---===[ Qubes Security Bulletin #36 ]===---
November 28, 2017
Xen hypervisor issue in populate-on-demand code (XSA-247)
Summary
========
The Xen Security Team has published Xen Security Advisory 247, which
concerns an issue with the populate-on-demand mechanism used to overbook
memory. We believe it would be very difficult, in practice, to exploit
this issue for privilege escalation.
Additionally, the Xen Security Team has published Xen Security
Advisory 246 (x86: infinite loop due to missing PoD error checking),
with the impact being denial of service only.
Technical details
==================
Xen Security Advisory 247 [1]:
| Certain actions require modification of entries in a guest's P2M
| (Physical-to-Machine) table. When large pages are in use for this
| table, such an operation may incur a memory allocation (to replace a
| large mapping with individual smaller ones). If this allocation
| fails, the p2m_set_entry() function will return an error.
|
| Unfortunately, several places in the populate-on-demand code don't
| check the return value of p2m_set_entry() to see if it succeeded.
|
| In some cases, the operation was meant to remove an entry from the p2m
| table. If this removal fails, a malicious guest may engineer that the
| page be returned to the Xen free list, making it available to be
| allocated to another domain, while it retains a writable mapping to
| the page.
|
| In other cases, the operation was meant to remove special
| populate-on-demand entries; if this removal fails, the internal
| accounting becomes inconsistent and may eventually hit a BUG().
|
| The allocation involved comes from a separate pool of memory created
| when the domain is created; under normal operating conditions it never
| fails, but a malicious guest may be able to engineer situations where
| this pool is exhausted.
|
| An unprivileged guest can retain a writable mapping of freed memory.
| Depending on how this page is used, it could result in either an
| information leak, or full privilege escalation.
|
| Alternatively, an unprivileged guest can cause Xen to hit a BUG(),
| causing a clean crash - ie, host-wide denial-of-service (DoS).
Xen Security Advisory 246 [2]:
| Failure to recognize errors being returned from low level functions in
| Populate on Demand (PoD) code may result in higher level code entering
| an infinite loop.
|
| A malicious HVM guest can cause one pcpu to permanently hang. This
| normally cascades into the whole system freezing, resulting in a a
| host Denial of Service (DoS).
Compromise Recovery
====================
Beginning 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. If you believe your system may be
compromised (perhaps because of the issue discussed in this bulletin),
please 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 problem discussed in this
bulletin are as follows:
For Qubes 3.2:
- Xen packages, version 4.6.6-35
For Qubes 4.0:
- Xen packages, version 4.8.2-11
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-247.html
[2] https://xenbits.xen.org/xsa/advisory-246.html
--
The Qubes Security Team
https://www.qubes-os.org/security/
- Xen packages, version 4.8.2-11
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-247.html
[2] https://xenbits.xen.org/xsa/advisory-246.html
--
The Qubes Security Team
https://www.qubes-os.org/security/
Xen Project Contributor Spotlight: Aporeto
https://blog.xenproject.org/2017/11/28/xen-project-contributor-spotlight-aporeto/
The Xen Project is comprised of a diverse set of member companies and contributors that are committed to the growth and success of the Xen Project Hypervisor. The Xen Project Hypervisor is a staple technology for server and cloud vendors, and is gaining traction in the embedded, security and automotive space. This blog series highlights […]
https://blog.xenproject.org/2017/11/28/xen-project-contributor-spotlight-aporeto/
The Xen Project is comprised of a diverse set of member companies and contributors that are committed to the growth and success of the Xen Project Hypervisor. The Xen Project Hypervisor is a staple technology for server and cloud vendors, and is gaining traction in the embedded, security and automotive space. This blog series highlights […]