RT @MikaelThalen: Or you secure copy & paste all links into a @QubesOS disposable VM & shame the security team for shaming you https://t.co/Fg7QgeRMN1
Twitter
Farhad Manjoo 🐝
The NYT security people regularly send us fake emails, to test us. Then they shame you if you click. It's a good practice. Keeps you sharp
RT @micahflee: @Hak5 @QubesOS protects against this if you use a USB VM. You can tell it to not trust USB keyboards or to ask before allowing them to type 17/18 https://t.co/MRhNEeY1l3
Twitter
Micah Lee
@Hak5 @QubesOS protects against this if you use a USB VM. You can tell it to not trust USB keyboards or to ask before allowing them to type 17/18
Presentations about QubeOS on Debconf later today.
https://debconf17.debconf.org/talks/16/
Recordings:
http://meetings-archive.debian.net/pub/debian-meetings/2017/debconf17/
https://debconf17.debconf.org/talks/16/
Recordings:
http://meetings-archive.debian.net/pub/debian-meetings/2017/debconf17/
The @QubeOS talk at Debconf starts here in a couple of minutes: https://debconf17.debconf.org/schedule/venue/4/
Qubes Security Bulletin #32: Xen hypervisor and Linux kernel vulnerabilities (XSA-226 through XSA-230):
https://t.co/a3J1LpNlUk
https://t.co/a3J1LpNlUk
GitHub
QubesOS/qubes-secpack
qubes-secpack - Qubes Security Pack
QSB #32: Xen hypervisor and Linux kernel vulnerabilities (XSA-226 through XSA-230)
https://www.qubes-os.org/news/2017/08/15/qsb-32/
Dear Qubes Community,
We have just published Qubes Security Bulletin (QSB) #32:
Xen hypervisor and Linux kernel vulnerabilities (XSA-226 through XSA-230).
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 #32 in the qubes-secpack:
https://github.com/QubesOS/qubes-secpack/blob/master/QSBs/qsb-032-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-226 through XSA-230 in the XSA Tracker:
https://www.qubes-os.org/security/xsa/
---===[ Qubes Security Bulletin #32 ]===---
August 15, 2017
Xen hypervisor and Linux kernel vulnerabilities (XSA-226 through XSA-230)
Summary
========
The Xen Security Team released several Xen Security Advisories today (XSA-226
through XSA-230) related to the grant tables mechanism used to share memory
between domains. The impact of these advisories ranges from data leaks to
system crashes and privilege escalations. See our commentary below for details.
Technical details
==================
Xen Security Advisory 226 [1]:
| Code to handle copy operations on transitive grants has built in retry
| logic, involving a function reinvoking itself with unchanged
| parameters. Such use assumes that the compiler would also translate
| this to a so called "tail call" when generating machine code.
| Empirically, this is not commonly the case, allowing for theoretically
| unbounded nesting of such function calls.
|
| A malicious or buggy guest may be able to crash Xen. Privilege
| escalation and information leaks cannot be ruled out.
Xen Security Advisory 227 [2]:
| When mapping a grant reference, a guest must inform Xen of where it
| would like the grant mapped. For PV guests, this is done by nominating
| an existing linear address, or an L1 pagetable entry, to be altered.
|
| Neither of these PV paths check for alignment of the passed parameter.
| The linear address path suitably truncates the linear address when
| calculating the L1 entry to use, but the path which uses a directly
| nominated L1 entry performs no checks.
|
| This causes Xen to make an incorrectly-aligned update to a pagetable,
| which corrupts both the intended entry and the subsequent entry with
| values which are largely guest controlled. If the misaligned value
| crosses a page boundary, then an arbitrary other heap page is
| corrupted.
|
| A PV guest can elevate its privilege to that of the host.
Xen Security Advisory 228 [3]:
| The grant table code in Xen has a bespoke semi-lockfree allocator for
| recording grant mappings ("maptrack" entries). This allocator has a
| race which allows the free list to be corrupted.
|
| Specifically: the code for removing an entry from the free list, prior
| to use, assumes (without locking) that if inspecting head item shows
| that it is not the tail, it will continue to not be the tail of the
| list if it is later found to be still the head and removed with
| cmpxchg. But the entry might have been removed and replaced, with the
| result that it might be the tail by then. (The invariants for the
| semi-lockfree data structure were never formally documented.)
|
| Additionally, a stolen entry is put on the free list with an incorrect
| link field, which will very likely corrupt the list.
|
| A malicious guest administrator can crash the host, and can probably
| escalate their privilege to that of the host.
Xen Security Advisory 229 [4]:
| The block layer in Linux may choose to merge adjacent block IO requests.
| When Linux is running as a Xen guest, the default merging algorithm is
https://www.qubes-os.org/news/2017/08/15/qsb-32/
Dear Qubes Community,
We have just published Qubes Security Bulletin (QSB) #32:
Xen hypervisor and Linux kernel vulnerabilities (XSA-226 through XSA-230).
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 #32 in the qubes-secpack:
https://github.com/QubesOS/qubes-secpack/blob/master/QSBs/qsb-032-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-226 through XSA-230 in the XSA Tracker:
https://www.qubes-os.org/security/xsa/
---===[ Qubes Security Bulletin #32 ]===---
August 15, 2017
Xen hypervisor and Linux kernel vulnerabilities (XSA-226 through XSA-230)
Summary
========
The Xen Security Team released several Xen Security Advisories today (XSA-226
through XSA-230) related to the grant tables mechanism used to share memory
between domains. The impact of these advisories ranges from data leaks to
system crashes and privilege escalations. See our commentary below for details.
Technical details
==================
Xen Security Advisory 226 [1]:
| Code to handle copy operations on transitive grants has built in retry
| logic, involving a function reinvoking itself with unchanged
| parameters. Such use assumes that the compiler would also translate
| this to a so called "tail call" when generating machine code.
| Empirically, this is not commonly the case, allowing for theoretically
| unbounded nesting of such function calls.
|
| A malicious or buggy guest may be able to crash Xen. Privilege
| escalation and information leaks cannot be ruled out.
Xen Security Advisory 227 [2]:
| When mapping a grant reference, a guest must inform Xen of where it
| would like the grant mapped. For PV guests, this is done by nominating
| an existing linear address, or an L1 pagetable entry, to be altered.
|
| Neither of these PV paths check for alignment of the passed parameter.
| The linear address path suitably truncates the linear address when
| calculating the L1 entry to use, but the path which uses a directly
| nominated L1 entry performs no checks.
|
| This causes Xen to make an incorrectly-aligned update to a pagetable,
| which corrupts both the intended entry and the subsequent entry with
| values which are largely guest controlled. If the misaligned value
| crosses a page boundary, then an arbitrary other heap page is
| corrupted.
|
| A PV guest can elevate its privilege to that of the host.
Xen Security Advisory 228 [3]:
| The grant table code in Xen has a bespoke semi-lockfree allocator for
| recording grant mappings ("maptrack" entries). This allocator has a
| race which allows the free list to be corrupted.
|
| Specifically: the code for removing an entry from the free list, prior
| to use, assumes (without locking) that if inspecting head item shows
| that it is not the tail, it will continue to not be the tail of the
| list if it is later found to be still the head and removed with
| cmpxchg. But the entry might have been removed and replaced, with the
| result that it might be the tail by then. (The invariants for the
| semi-lockfree data structure were never formally documented.)
|
| Additionally, a stolen entry is put on the free list with an incorrect
| link field, which will very likely corrupt the list.
|
| A malicious guest administrator can crash the host, and can probably
| escalate their privilege to that of the host.
Xen Security Advisory 229 [4]:
| The block layer in Linux may choose to merge adjacent block IO requests.
| When Linux is running as a Xen guest, the default merging algorithm is
| replaced with a Xen-specific one. When Linux is running as an x86 PV
| guest, some BIO's are erroneously merged, corrupting the data stream
| to/from the block device.
|
| This can result in incorrect access to an uncontrolled adjacent frame.
|
| A buggy or malicious guest can cause Linux to read or write incorrect
| memory when processing a block stream. This could leak information from
| other guests in the system or from Xen itself, or be used to DoS or
| escalate privilege within the system.
Xen Security Advisory 230 [5]:
| Xen maintains the _GTF_{read,writ}ing bits as appropriate, to inform the
| guest that a grant is in use. A guest is expected not to modify the
| grant details while it is in use, whereas the guest is free to
| modify/reuse the grant entry when it is not in use.
|
| Under some circumstances, Xen will clear the status bits too early,
| incorrectly informing the guest that the grant is no longer in use.
|
| A guest may prematurely believe that a granted frame is safely private
| again, and reuse it in a way which contains sensitive information, while
| the domain on the far end of the grant is still using the grant.
Commentary from the Qubes Security Team
========================================
It looks like the most severe of the vulnerabilities published today is
XSA-227, which is another example of a bug in memory management code for
para-virtualized (PV) VMs. As discussed before, in Qubes 4.0 [6], we've decided
to retire the use of PV virtualization mode in favour of fully virtualized VMs,
precisely in order to to prevent this class of vulnerabilities from affecting
the security of Qubes OS. We note however, that Qubes 3.2 uses PV for all VMs
by default.
XSA-228 seems to be another potentially serious vulnerability. While this does
not seem to be limited only to PV virtualization, we should note that it is a
race condition type of bug. Such types of vulnerabilities are typically
significantly more difficult to reliably exploit in practice.
The remaining vulnerabilities (XSA-229 and XSA-230) look even more theoretical.
We should also note that XSA-229 is a vulnerability in the Linux kernel's
implementation of the Xen PV block (disk) backend, not in the Xen hypervisor.
The Qubes architecture partly mitigates potential successful attacks exploiting
this vulnerability thanks to offloading some of the storage backend to USB and
(optionally) other VMs. The main system block backend still runs in dom0,
however, hence the inclusion of this bug in the bulletin.
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-29
- Kernel packages, version 4.9.35-20
For Qubes 4.0:
- Xen packages, version 4.8.1-5
- Kernel packages, version 4.9.35-20
The packages are to be installed in dom0 via the qubes-dom0-update command or
via the Qubes VM Manager. A system restart will be required afterwards.
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 and kernel binaries,
and because of the regenerated initramfs.
These packages will migrate to the current (stable) repository over the next
two weeks after being tested by the community.
Credits
========
See the original Xen Security Advisories.
References
===========
[1] https://xenbits.xen.org/xsa/advisory-226.html
[2] https://xenbits.xen.org/xsa/advisory-227.html
| guest, some BIO's are erroneously merged, corrupting the data stream
| to/from the block device.
|
| This can result in incorrect access to an uncontrolled adjacent frame.
|
| A buggy or malicious guest can cause Linux to read or write incorrect
| memory when processing a block stream. This could leak information from
| other guests in the system or from Xen itself, or be used to DoS or
| escalate privilege within the system.
Xen Security Advisory 230 [5]:
| Xen maintains the _GTF_{read,writ}ing bits as appropriate, to inform the
| guest that a grant is in use. A guest is expected not to modify the
| grant details while it is in use, whereas the guest is free to
| modify/reuse the grant entry when it is not in use.
|
| Under some circumstances, Xen will clear the status bits too early,
| incorrectly informing the guest that the grant is no longer in use.
|
| A guest may prematurely believe that a granted frame is safely private
| again, and reuse it in a way which contains sensitive information, while
| the domain on the far end of the grant is still using the grant.
Commentary from the Qubes Security Team
========================================
It looks like the most severe of the vulnerabilities published today is
XSA-227, which is another example of a bug in memory management code for
para-virtualized (PV) VMs. As discussed before, in Qubes 4.0 [6], we've decided
to retire the use of PV virtualization mode in favour of fully virtualized VMs,
precisely in order to to prevent this class of vulnerabilities from affecting
the security of Qubes OS. We note however, that Qubes 3.2 uses PV for all VMs
by default.
XSA-228 seems to be another potentially serious vulnerability. While this does
not seem to be limited only to PV virtualization, we should note that it is a
race condition type of bug. Such types of vulnerabilities are typically
significantly more difficult to reliably exploit in practice.
The remaining vulnerabilities (XSA-229 and XSA-230) look even more theoretical.
We should also note that XSA-229 is a vulnerability in the Linux kernel's
implementation of the Xen PV block (disk) backend, not in the Xen hypervisor.
The Qubes architecture partly mitigates potential successful attacks exploiting
this vulnerability thanks to offloading some of the storage backend to USB and
(optionally) other VMs. The main system block backend still runs in dom0,
however, hence the inclusion of this bug in the bulletin.
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-29
- Kernel packages, version 4.9.35-20
For Qubes 4.0:
- Xen packages, version 4.8.1-5
- Kernel packages, version 4.9.35-20
The packages are to be installed in dom0 via the qubes-dom0-update command or
via the Qubes VM Manager. A system restart will be required afterwards.
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 and kernel binaries,
and because of the regenerated initramfs.
These packages will migrate to the current (stable) repository over the next
two weeks after being tested by the community.
Credits
========
See the original Xen Security Advisories.
References
===========
[1] https://xenbits.xen.org/xsa/advisory-226.html
[2] https://xenbits.xen.org/xsa/advisory-227.html
XSA-235 does not affect the security of Qubes OS
https://www.qubes-os.org/news/2017/08/23/xsa-235/
The Xen Project has published Xen Security Advisory 235 (XSA-235).
This XSA does not affect the security of Qubes OS, and no user action is necessary.
This XSA has been added to the XSA Tracker (https://www.qubes-os.org/security/xsa/):
https://www.qubes-os.org/security/xsa/#235
https://www.qubes-os.org/news/2017/08/23/xsa-235/
The Xen Project has published Xen Security Advisory 235 (XSA-235).
This XSA does not affect the security of Qubes OS, and no user action is necessary.
This XSA has been added to the XSA Tracker (https://www.qubes-os.org/security/xsa/):
https://www.qubes-os.org/security/xsa/#235
My GSoC experience: Fuzzing the hypervisor
https://blog.xenproject.org/2017/08/25/my-gsoc-experience-fuzzing-the-hypervisor/
This blog post was written by Felix Schmoll, currently studying Mechanical Engineering at ETH Zurich. After obtaining a Bachelor in Computer Science from Jacobs University he spent the summer working on fuzzing the hypervisor as a Google Summer of Code student. His main interests in code are low-level endeavours and building scalable applications. Five months ago, […]
https://blog.xenproject.org/2017/08/25/my-gsoc-experience-fuzzing-the-hypervisor/
This blog post was written by Felix Schmoll, currently studying Mechanical Engineering at ETH Zurich. After obtaining a Bachelor in Computer Science from Jacobs University he spent the summer working on fuzzing the hypervisor as a Google Summer of Code student. His main interests in code are low-level endeavours and building scalable applications. Five months ago, […]
My GSoC Experience: Allow Setting up Shared Memory Regions between VMs from xl Config File
https://blog.xenproject.org/2017/08/29/my-gsoc-experience-allow-setting-up-shared-memory-regions-between-vms-from-xl-config-file/
This blog was written by Zhongze Liu. Zhongze Liu is a student studying information security in Huazhong University of Science and Technology in Wuhan, China. He recently took part in GSoC 2017 where he worked closely with the Xen Project community on “Allowing Sharing Memory Regions between VMs from xl Config.” His interests are low-level hacking and […]
https://blog.xenproject.org/2017/08/29/my-gsoc-experience-allow-setting-up-shared-memory-regions-between-vms-from-xl-config-file/
This blog was written by Zhongze Liu. Zhongze Liu is a student studying information security in Huazhong University of Science and Technology in Wuhan, China. He recently took part in GSoC 2017 where he worked closely with the Xen Project community on “Allowing Sharing Memory Regions between VMs from xl Config.” His interests are low-level hacking and […]
Xen Project 4.8.2 is available
https://blog.xenproject.org/2017/09/06/xen-project-4-8-2-is-available/
I am pleased to announce the release of Xen 4.8.2. Xen Project Maintenance releases are released in line with our Maintenance Release Policy. We recommend that all users of the 4.8 stable series update to the latest point release. The release is available from its git repository xenbits.xen.org/gitweb/?p=xen.git;a=shortlog;h=refs/heads/stable-4.8 (tag RELEASE-4.8.2) or from the XenProject download […]
https://blog.xenproject.org/2017/09/06/xen-project-4-8-2-is-available/
I am pleased to announce the release of Xen 4.8.2. Xen Project Maintenance releases are released in line with our Maintenance Release Policy. We recommend that all users of the 4.8 stable series update to the latest point release. The release is available from its git repository xenbits.xen.org/gitweb/?p=xen.git;a=shortlog;h=refs/heads/stable-4.8 (tag RELEASE-4.8.2) or from the XenProject download […]
RT @golemproject: We are going to livestream our Berlin event @blueyard, Thursday Sep 7! Feat. @QubesOS @streamrinc & @omise_go #compute #security #ethereum https://t.co/OcSzcBZqgN
Twitter
golem
We are going to livestream our Berlin event @blueyard, Thursday Sep 7! Feat. @QubesOS @streamrinc & @omise_go #compute #security #ethereum
RT @rootkovska: Yesterday I discussed the (long-term) vision of @QubesOS running on top of @golemproject decentralized compute cloud, announced cooperation.
RT @julianzawist: I am excited & think this will result in great advancements for both @QubesOS and @golemproject https://t.co/vqal5Hf5hw
Twitter
Joanna Rutkowska
Yesterday I discussed the (long-term) vision of @QubesOS running on top of @golemproject decentralized compute cloud, announced cooperation.
Forwarded from Pavel Durov
If you haven’t read it yet, here’s the full story about the US agencies’ attempts to infiltrate Telegram last year: https://thebaffler.com/salvos/the-crypto-keepers-levine
It tells how the FBI tried to influence me and bribe our engineer in May 2016 to make Telegram less secure. Luckily, since neither of us are US citizens, we could afford to refuse their offers and I was able to tell the public about these attempts. If we were American citizens, the FBI would have likely tried to silence us using a legal procedure called a "gag order" – when the US authorities can not only demand that you do something (like plant a backdoor into your app), but also prohibit you from telling the public about it (otherwise you can end up in jail).
That whole story made me ask myself this question: if our team experienced such pressure during just one week’s trip to America, what kind of pressure are US-based tech companies facing every day? How can a privacy oriented company permanently operate from America? We can hope that the open US legal system would defend them, but due to the secrecy of these “gag orders” we would never even know if things went wrong. And unfortunately, Edward Snowden’s revelations confirm some of the worst fears.
The article also provides facts that confirm something that I always feared could be true – that some of the famous and most vocal US-based influencers within the cryptography world are sponsored by the US government to push the agenda of its agencies. Some past cases are widely known (like NSA infiltrating RSA), but it looks like the level of collaboration between US agencies and these influential “privacy advocates” is much deeper.
All of this makes protecting privacy really hard, particularly considering the fact that Google and Apple – the two companies which we are dependent on for mobile operating systems – are based in the US. I don't see any easy recipe or solution to fix this. I wish one day huge companies like Apple and Google can become independent of any government that can distort the mission of their founders (maybe start their own countries?).
Until then, I’ll continue doing my part building Telegram and protecting our users, even if that will require speaking out under gag orders. I know this can probably get me into trouble some day, as it did in the past when I was living in Russia. But this is the only way I can imagine myself going forward, so I don't have and won’t have any regrets. It’s all worth it because of you guys – the millions of users who entrusted their private data to Telegram.
It tells how the FBI tried to influence me and bribe our engineer in May 2016 to make Telegram less secure. Luckily, since neither of us are US citizens, we could afford to refuse their offers and I was able to tell the public about these attempts. If we were American citizens, the FBI would have likely tried to silence us using a legal procedure called a "gag order" – when the US authorities can not only demand that you do something (like plant a backdoor into your app), but also prohibit you from telling the public about it (otherwise you can end up in jail).
That whole story made me ask myself this question: if our team experienced such pressure during just one week’s trip to America, what kind of pressure are US-based tech companies facing every day? How can a privacy oriented company permanently operate from America? We can hope that the open US legal system would defend them, but due to the secrecy of these “gag orders” we would never even know if things went wrong. And unfortunately, Edward Snowden’s revelations confirm some of the worst fears.
The article also provides facts that confirm something that I always feared could be true – that some of the famous and most vocal US-based influencers within the cryptography world are sponsored by the US government to push the agenda of its agencies. Some past cases are widely known (like NSA infiltrating RSA), but it looks like the level of collaboration between US agencies and these influential “privacy advocates” is much deeper.
All of this makes protecting privacy really hard, particularly considering the fact that Google and Apple – the two companies which we are dependent on for mobile operating systems – are based in the US. I don't see any easy recipe or solution to fix this. I wish one day huge companies like Apple and Google can become independent of any government that can distort the mission of their founders (maybe start their own countries?).
Until then, I’ll continue doing my part building Telegram and protecting our users, even if that will require speaking out under gag orders. I know this can probably get me into trouble some day, as it did in the past when I was living in Russia. But this is the only way I can imagine myself going forward, so I don't have and won’t have any regrets. It’s all worth it because of you guys – the millions of users who entrusted their private data to Telegram.
The Baffler
The Crypto- Keepers
If apps like Signal really posed a threat to the NSA’s surveillance power, why would the U.S. government continue to fund them?
RT @golemproject: Video report & @julianzawist's blogpost on Berlin https://t.co/w366VGaRdC #Ethereum #TrueCloud #Cooperation @omise_go @QubesOS @streamrinc
The Golem Project
After Berlin — the Spirit of Cooperation
We hope you enjoyed Golem’s meetup in Berlin as much as we did. Reflecting on it over the weekend, the team thought it was a great event…
QSB #33: Xen hypervisor (XSA-231 through XSA-234)
https://www.qubes-os.org/news/2017/09/12/qsb-33/
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
https://www.qubes-os.org/news/2017/09/12/qsb-33/
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/
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/