Xen Project Hypervisor Power Management: Suspend-to-RAM on Arm Architectures
https://blog.xenproject.org/2018/07/19/xen-project-hypervisor-power-management-suspend-to-ram-on-arm-architectures/
This is the second part of the Xen Project Hypervisor series on power management. The first article focused on how virtualization and power management are coalescing into an energy-aware hypervisor. In this post, the focus is on a project that was started to lay the foundation for full-scale power management for applications involving the Xen […]
https://blog.xenproject.org/2018/07/19/xen-project-hypervisor-power-management-suspend-to-ram-on-arm-architectures/
This is the second part of the Xen Project Hypervisor series on power management. The first article focused on how virtualization and power management are coalescing into an energy-aware hypervisor. In this post, the focus is on a project that was started to lay the foundation for full-scale power management for applications involving the Xen […]
Comment on What’s New in the Xen Project Hypervisor 4.11 by Xen Hypervisor 4.11 Released, New Browsh Text-Based Browser, Finney Cryptocurrency Phone, GNOME Hiring and More | Linux Admins – News and Blog
https://blog.xenproject.org/2018/07/10/whats-new-in-the-xen-project-hypervisor-4-11/#comment-528
[…] Xen Hypervisor 4.11 was released yesterday. In this release “PVH Dom0 support is now available as experimental feature and […]
https://blog.xenproject.org/2018/07/10/whats-new-in-the-xen-project-hypervisor-4-11/#comment-528
[…] Xen Hypervisor 4.11 was released yesterday. In this release “PVH Dom0 support is now available as experimental feature and […]
XSA-274 does not affect the security of Qubes OS
https://www.qubes-os.org/news/2018/07/25/xsa-274-qubes-not-affected/
The Xen Project has published Xen Security Advisory 274 (XSA-274). 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/#274
https://www.qubes-os.org/news/2018/07/25/xsa-274-qubes-not-affected/
The Xen Project has published Xen Security Advisory 274 (XSA-274). 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/#274
A Recap of the Xen Project Developer and Design Summit: Community Health, Development Trends, Coding Changes and More
https://blog.xenproject.org/2018/07/27/a-recap-of-the-xen-project-developer-and-design-summit-community-health-development-trends-coding-changes-and-more/
We were extremely thrilled to host our Xen Project Developer and Design Summit in Nanjing Jiangning, China this June. The event brought together our community and power users under one roof to collaborate and to learn more about the future of our project. It also gave us the opportunity to connect with a large group […]
https://blog.xenproject.org/2018/07/27/a-recap-of-the-xen-project-developer-and-design-summit-community-health-development-trends-coding-changes-and-more/
We were extremely thrilled to host our Xen Project Developer and Design Summit in Nanjing Jiangning, China this June. The event brought together our community and power users under one roof to collaborate and to learn more about the future of our project. It also gave us the opportunity to connect with a large group […]
Killing Processes that Don’t Want to be Killed
https://blog.xenproject.org/2018/08/01/killing-processes-that-dont-want-to-be-killed/
This article originally appeared on lwn.net. Suppose you have a program running on your system that you don’t quite trust. Maybe it’s a program submitted by a student to an automated grading system. Or maybe it’s a QEMU device model running in a Xen control domain ("domain 0" or “dom0”), and you want to make sure […]
https://blog.xenproject.org/2018/08/01/killing-processes-that-dont-want-to-be-killed/
This article originally appeared on lwn.net. Suppose you have a program running on your system that you don’t quite trust. Maybe it’s a program submitted by a student to an automated grading system. Or maybe it’s a QEMU device model running in a Xen control domain ("domain 0" or “dom0”), and you want to make sure […]
[Video] Micah Lee presents Qubes OS at HOPE 2018
https://www.qubes-os.org/news/2018/08/03/micah-lee-hope-conf-2018/
Micah Lee (https://micahflee.com/), a long-time Qubes advocate (https://www.qubes-os.org/experts/), presented Qubes OS: The Operating
System That Can Protect You Even If You Get Hacked (https://www.hope.net/schedule.html#-qubes-os-the-operating-system-that-can-protect-you-even-if-you-get-hacked-) at the Circle of HOPE (https://www.hope.net/index.html)
conference, which took place July 20-22, 2018 in New York City. A video
recording of Micah’s presentation is available here (https://livestream.com/internetsociety2/hope/videos/178431606).
https://www.qubes-os.org/news/2018/08/03/micah-lee-hope-conf-2018/
Micah Lee (https://micahflee.com/), a long-time Qubes advocate (https://www.qubes-os.org/experts/), presented Qubes OS: The Operating
System That Can Protect You Even If You Get Hacked (https://www.hope.net/schedule.html#-qubes-os-the-operating-system-that-can-protect-you-even-if-you-get-hacked-) at the Circle of HOPE (https://www.hope.net/index.html)
conference, which took place July 20-22, 2018 in New York City. A video
recording of Micah’s presentation is available here (https://livestream.com/internetsociety2/hope/videos/178431606).
Whonix 14 has been released
https://www.qubes-os.org/news/2018/08/07/whonix-14-has-been-released/
After more than two years of development, the Whonix Project is proud
to announce the release of Whonix 14.
Whonix 14 is based on the Debian stretch (Debian 9) distribution which
was released in June 2017. This means users have access to many new
software packages in concert with existing packages such as a modern
branch of GNuPG, and more. [1 (https://www.debian.org/News/2017/20170617)][2 (https://www.debian.org/releases/stable/amd64/release-notes/)][3 (https://www.debian.org/releases/stable/i386/release-notes/)]
Major Changes and New Features
Whonix 14 contains extensive security and usability improvements, new
features and bug fixes. For a detailed denoscription of these and other
changes, please refer to the official release notes. [4 (https://whonix.org/wiki/Whonix_Release_Notes#Whonix_14)]
Rebased Whonix on Debian stretch (Debian 9).
Whonix 14 is 64-bit (amd64) only - 32-bit (i386) images will no
longer be built and made available for download. [5]
The new Anon Connection Wizard [6 (https://whonix.org/wiki/Anon_Connection_Wizard)] feature in Whonix simplifies
connections to the Tor network via a Tor bridge and/or a proxy.
The Tor pluggable transport meek_lite [7 (https://www.whonix.org/blog/meek_lite-whonix-14)] is now supported,
making it much easier to connect to the Tor network in heavily
censored areas, like China. [8 (https://github.com/Yawning/obfs4/commit/611205be681322883a4d73dd00fcb13c4352fe53)]
Onioncircuits are installed by default in Whonix. [9 (https://packages.debian.org/stretch/onioncircuits)]
Tails’ onion-grater program has been implemented to enable
OnionShare, Ricochet and Zeronet compatibility with Whonix. [10 (https://phabricator.whonix.org/T657)]
Onion sources are now preferred for Whonix updates/upgrades for
greater security.
Reduced the size of the default, binary Whonix images by
approximately 35 per cent using zerofree. [11 (https://phabricator.whonix.org/T790)] [12]
Updated Tor to version 3.3.7 (stable) release to enable full v3
onion functionality for both hosting of onion services and access to
v3 onion addresses in Tor Browser.
Created the grub-live package [13 (https://whonix.org/wiki/Whonix_Live)] which can run Whonix as a
live system on non-Qubes-Whonix platforms. [14]
Corrected and hardened various AppArmor profiles to ensure the
correct functioning of Tor Browser, obfsproxy and other applications.
Known Issues
Desktop shortcuts are no longer available in non-Qubes-Whonix.
OnionShare is not installed by default in Whonix 14 as it is not in
the stretch repository. [15 (https://packages.debian.org/search?searchon=names&keywords=onionshare)] It can still be manually installed by
following the Whonix wiki instructions [16 (https://whonix.org/wiki/Onionshare)] or building it from source
code. [17 (https://github.com/micahflee/onionshare/blob/master/BUILD.md#gnulinux)]
Enabling seccomp (Sandbox 1) in /usr/local/etc/torrc.d/50_user.conf
causes the Tor process to crash if a Tor version lower than 0.3.3 is
used. [18 (https://trac.torproject.org/projects/tor/ticket/22605)] [19 (https://packages.debian.org/stretch/tor)]
While there may be other issues that exist in this declared stable
release, every effort has been made to address major known problems.
Please report any other issues to us in the forums, after first
searching for whether it is already known.
https://www.whonix.org/wiki/Known_Issues
Download Whonix 14
Whonix is cross-platform and can be installed on the Windows, macOS,
Linux or Qubes operating systems. Choose your operating system from
the link below and follow the instructions to install it.
https://www.whonix.org/download/
Upgrade to Whonix 14
Current Whonix users (or those with 32-bit hardware) who would prefer
to upgrade their existing Whonix 13 platform should follow the upgrade
instructions below.
https://www.qubes-os.org/news/2018/08/07/whonix-14-has-been-released/
After more than two years of development, the Whonix Project is proud
to announce the release of Whonix 14.
Whonix 14 is based on the Debian stretch (Debian 9) distribution which
was released in June 2017. This means users have access to many new
software packages in concert with existing packages such as a modern
branch of GNuPG, and more. [1 (https://www.debian.org/News/2017/20170617)][2 (https://www.debian.org/releases/stable/amd64/release-notes/)][3 (https://www.debian.org/releases/stable/i386/release-notes/)]
Major Changes and New Features
Whonix 14 contains extensive security and usability improvements, new
features and bug fixes. For a detailed denoscription of these and other
changes, please refer to the official release notes. [4 (https://whonix.org/wiki/Whonix_Release_Notes#Whonix_14)]
Rebased Whonix on Debian stretch (Debian 9).
Whonix 14 is 64-bit (amd64) only - 32-bit (i386) images will no
longer be built and made available for download. [5]
The new Anon Connection Wizard [6 (https://whonix.org/wiki/Anon_Connection_Wizard)] feature in Whonix simplifies
connections to the Tor network via a Tor bridge and/or a proxy.
The Tor pluggable transport meek_lite [7 (https://www.whonix.org/blog/meek_lite-whonix-14)] is now supported,
making it much easier to connect to the Tor network in heavily
censored areas, like China. [8 (https://github.com/Yawning/obfs4/commit/611205be681322883a4d73dd00fcb13c4352fe53)]
Onioncircuits are installed by default in Whonix. [9 (https://packages.debian.org/stretch/onioncircuits)]
Tails’ onion-grater program has been implemented to enable
OnionShare, Ricochet and Zeronet compatibility with Whonix. [10 (https://phabricator.whonix.org/T657)]
Onion sources are now preferred for Whonix updates/upgrades for
greater security.
Reduced the size of the default, binary Whonix images by
approximately 35 per cent using zerofree. [11 (https://phabricator.whonix.org/T790)] [12]
Updated Tor to version 3.3.7 (stable) release to enable full v3
onion functionality for both hosting of onion services and access to
v3 onion addresses in Tor Browser.
Created the grub-live package [13 (https://whonix.org/wiki/Whonix_Live)] which can run Whonix as a
live system on non-Qubes-Whonix platforms. [14]
Corrected and hardened various AppArmor profiles to ensure the
correct functioning of Tor Browser, obfsproxy and other applications.
Known Issues
Desktop shortcuts are no longer available in non-Qubes-Whonix.
OnionShare is not installed by default in Whonix 14 as it is not in
the stretch repository. [15 (https://packages.debian.org/search?searchon=names&keywords=onionshare)] It can still be manually installed by
following the Whonix wiki instructions [16 (https://whonix.org/wiki/Onionshare)] or building it from source
code. [17 (https://github.com/micahflee/onionshare/blob/master/BUILD.md#gnulinux)]
Enabling seccomp (Sandbox 1) in /usr/local/etc/torrc.d/50_user.conf
causes the Tor process to crash if a Tor version lower than 0.3.3 is
used. [18 (https://trac.torproject.org/projects/tor/ticket/22605)] [19 (https://packages.debian.org/stretch/tor)]
While there may be other issues that exist in this declared stable
release, every effort has been made to address major known problems.
Please report any other issues to us in the forums, after first
searching for whether it is already known.
https://www.whonix.org/wiki/Known_Issues
Download Whonix 14
Whonix is cross-platform and can be installed on the Windows, macOS,
Linux or Qubes operating systems. Choose your operating system from
the link below and follow the instructions to install it.
https://www.whonix.org/download/
Upgrade to Whonix 14
Current Whonix users (or those with 32-bit hardware) who would prefer
to upgrade their existing Whonix 13 platform should follow the upgrade
instructions below.
https://whonix.org/wiki/Upgrading_Whonix_13_to_Whonix_14
What’s Next?
Work on Whonix 15 is ongoing and interested users can refer to the
roadmap to see where Whonix is heading. [20 (https://phabricator.whonix.org/maniphest/query/open/)]
Developer priorities are currently focused on easing the transition to
the next Debian release due in 2019 (“buster”; Debian 10) and
squashing existing bugs, rather than implementing new features.
We need your help and there are various ways to contribute to Whonix -
donating or investing your time will help the project immensely. Come
and talk with us! [21 (https://forums.whonix.org/)]
Notes
[5] Whonix 13 users with 32-bit systems can however upgrade their
platform by following the available wiki instructions, rather than
download new Whonix-WS and Whonix-GW images.
[12] VirtualBox .ova and libvirt qcow2 raw images. The Whonix-Gateway
is reduced from 1.7 GB to 1.1 GB, while the Whonix-Workstation is
reduced from 2 GB to 1.3 GB.
[14] grub-live is optional and requires the user to first enable it
manually.
This post has been formatted for presentation on the Qubes website from the original mailing list announcement (https://groups.google.com/forum/#!topic/qubes-users/5mBXxQ_LSvg).
What’s Next?
Work on Whonix 15 is ongoing and interested users can refer to the
roadmap to see where Whonix is heading. [20 (https://phabricator.whonix.org/maniphest/query/open/)]
Developer priorities are currently focused on easing the transition to
the next Debian release due in 2019 (“buster”; Debian 10) and
squashing existing bugs, rather than implementing new features.
We need your help and there are various ways to contribute to Whonix -
donating or investing your time will help the project immensely. Come
and talk with us! [21 (https://forums.whonix.org/)]
Notes
[5] Whonix 13 users with 32-bit systems can however upgrade their
platform by following the available wiki instructions, rather than
download new Whonix-WS and Whonix-GW images.
[12] VirtualBox .ova and libvirt qcow2 raw images. The Whonix-Gateway
is reduced from 1.7 GB to 1.1 GB, while the Whonix-Workstation is
reduced from 2 GB to 1.3 GB.
[14] grub-live is optional and requires the user to first enable it
manually.
This post has been formatted for presentation on the Qubes website from the original mailing list announcement (https://groups.google.com/forum/#!topic/qubes-users/5mBXxQ_LSvg).
Get an Introduction to Working with the Xen Project Hypervisor and More at Open Source Summit #OSSummit
https://blog.xenproject.org/2018/08/14/get-an-introduction-to-working-with-the-xen-project-hypervisor-and-more-at-open-source-summit-ossummit/
Open Source Summit is the premier event to get introduced to open source and to learn more about the trends that are surrounding this space. This year’s Open Source Summit will be held in Vancouver, BC from August 29 – 31. The event covers a wide range of topics from blockchain to security to virtualization […]
https://blog.xenproject.org/2018/08/14/get-an-introduction-to-working-with-the-xen-project-hypervisor-and-more-at-open-source-summit-ossummit/
Open Source Summit is the premier event to get introduced to open source and to learn more about the trends that are surrounding this space. This year’s Open Source Summit will be held in Vancouver, BC from August 29 – 31. The event covers a wide range of topics from blockchain to security to virtualization […]
QSB #42: Linux netback driver OOB access in hash handling (XSA-270)
https://www.qubes-os.org/news/2018/08/14/qsb-42/
Dear Qubes Community,
We have just published Qubes Security Bulletin (QSB) #42: Linux netback
driver OOB access in hash handling (XSA-270). 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 #42 in the qubes-secpack:
https://github.com/QubesOS/qubes-secpack/blob/master/QSBs/qsb-042-2018.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-270 in the XSA Tracker:
https://www.qubes-os.org/security/xsa/#270
---===[ Qubes Security Bulletin #42 ]===---
2018-08-14
Linux netback driver OOB access in hash handling (XSA-270)
Summary
========
On 2018-08-14, the Xen Security Team published Xen Security Advisory
270 (XSA-270) [1] with the following denoscription:
| Linux's netback driver allows frontends to control mapping of requests
| to request queues. When processing a request to set or change this
| mapping, some input validation was missing or flawed.
|
| A malicious or buggy frontend may cause the (usually privileged)
| backend to make out of bounds memory accesses, potentially resulting
| in one or more of privilege escalation, Denial of Service (DoS), or
| information leaks.
Impact for Qubes
=================
The bug affects only the network backend driver, which means that any
qube with access to a network can attack the qube that provides it with
access to that network. For example:
- In a default configuration, any network-connected AppVM can attack
sys-firewall, which can in turn attack sys-net.
- Any qube connected to a VPN Gateway [2] can attack the VPN Gateway
and potentially steal VPN credentials.
- Any Whonix Workstation can attack the Whonix Gateway to which it is
connected, potentially compromising anonymity.
It is important to note, however, that dom0 and network-disconnected
qubes are not affected.
Patching
=========
The Xen Project has provided patches to fix this issue.
The specific packages that resolve the problems discussed in this
bulletin are as follows:
For Qubes 3.2:
- kernel packages, version 4.14.57-2
- kernel-latest packages, version 4.17.9-2
For Qubes 4.0:
- kernel packages, version 4.14.57-2
- kernel-latest packages, version 4.17.9-2
The kernel-latest packages are not installed by default. If you do not
already have them installed, then it is not necessary to install them in
order to fix this issue. However, if you already have them installed,
then we recommend that you update them to the version containing the fix
for this issue.
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 restart of all network-providing qubes 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
Linux binaries.
Users who are using in-VM kernels [3] for any of their VMs should note
that installing the packages listed above will not update their in-VM
kernels. We recommend that these users install updates for their in-VM
kernels when the appropriate distributions provide kernel updates that
fix this issue.
Credits
========
See the original Xen Security Advisory.
References
===========
https://www.qubes-os.org/news/2018/08/14/qsb-42/
Dear Qubes Community,
We have just published Qubes Security Bulletin (QSB) #42: Linux netback
driver OOB access in hash handling (XSA-270). 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 #42 in the qubes-secpack:
https://github.com/QubesOS/qubes-secpack/blob/master/QSBs/qsb-042-2018.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-270 in the XSA Tracker:
https://www.qubes-os.org/security/xsa/#270
---===[ Qubes Security Bulletin #42 ]===---
2018-08-14
Linux netback driver OOB access in hash handling (XSA-270)
Summary
========
On 2018-08-14, the Xen Security Team published Xen Security Advisory
270 (XSA-270) [1] with the following denoscription:
| Linux's netback driver allows frontends to control mapping of requests
| to request queues. When processing a request to set or change this
| mapping, some input validation was missing or flawed.
|
| A malicious or buggy frontend may cause the (usually privileged)
| backend to make out of bounds memory accesses, potentially resulting
| in one or more of privilege escalation, Denial of Service (DoS), or
| information leaks.
Impact for Qubes
=================
The bug affects only the network backend driver, which means that any
qube with access to a network can attack the qube that provides it with
access to that network. For example:
- In a default configuration, any network-connected AppVM can attack
sys-firewall, which can in turn attack sys-net.
- Any qube connected to a VPN Gateway [2] can attack the VPN Gateway
and potentially steal VPN credentials.
- Any Whonix Workstation can attack the Whonix Gateway to which it is
connected, potentially compromising anonymity.
It is important to note, however, that dom0 and network-disconnected
qubes are not affected.
Patching
=========
The Xen Project has provided patches to fix this issue.
The specific packages that resolve the problems discussed in this
bulletin are as follows:
For Qubes 3.2:
- kernel packages, version 4.14.57-2
- kernel-latest packages, version 4.17.9-2
For Qubes 4.0:
- kernel packages, version 4.14.57-2
- kernel-latest packages, version 4.17.9-2
The kernel-latest packages are not installed by default. If you do not
already have them installed, then it is not necessary to install them in
order to fix this issue. However, if you already have them installed,
then we recommend that you update them to the version containing the fix
for this issue.
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 restart of all network-providing qubes 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
Linux binaries.
Users who are using in-VM kernels [3] for any of their VMs should note
that installing the packages listed above will not update their in-VM
kernels. We recommend that these users install updates for their in-VM
kernels when the appropriate distributions provide kernel updates that
fix this issue.
Credits
========
See the original Xen Security Advisory.
References
===========
XSA-268, XSA-269, XSA-271, and XSA-272 do not affect the security of Qubes OS
https://www.qubes-os.org/news/2018/08/14/xsa-268-269-271-272-qubes-not-affected/
Dear Qubes Community,
The Xen Project has published Xen Security Advisories 268, 269, 271,
and 272 (XSA-268, XSA-269, XSA-271, and XSA-272, respectively). These
XSAs do not affect the security of Qubes OS, and no user action is
necessary.
These XSAs have been added to the XSA Tracker (https://www.qubes-os.org/security/xsa/):
https://www.qubes-os.org/security/xsa/#268
https://www.qubes-os.org/security/xsa/#269
https://www.qubes-os.org/security/xsa/#271
https://www.qubes-os.org/security/xsa/#272
https://www.qubes-os.org/news/2018/08/14/xsa-268-269-271-272-qubes-not-affected/
Dear Qubes Community,
The Xen Project has published Xen Security Advisories 268, 269, 271,
and 272 (XSA-268, XSA-269, XSA-271, and XSA-272, respectively). These
XSAs do not affect the security of Qubes OS, and no user action is
necessary.
These XSAs have been added to the XSA Tracker (https://www.qubes-os.org/security/xsa/):
https://www.qubes-os.org/security/xsa/#268
https://www.qubes-os.org/security/xsa/#269
https://www.qubes-os.org/security/xsa/#271
https://www.qubes-os.org/security/xsa/#272
Whonix 13 approaching EOL
https://www.qubes-os.org/news/2018/08/24/whonix-13-approaching-eol/
With the recent release of Whonix 14 (https://www.qubes-os.org/news/2018/08/07/whonix-14-has-been-released/), Whonix 13 will reach EOL (end-of-life)
on 2018-09-30. We strongly recommend that all Qubes users who have Whonix
TemplateVMs (https://www.qubes-os.org/doc/whonix/) or StandaloneVMs (https://www.qubes-os.org/doc/glossary/#standalonevm) upgrade them to Whonix 14 by 2018-09-30. The
Whonix Project (https://www.whonix.org/) provides step-by-step upgrade instructions for upgrading from
Whonix 13 to 14 (https://www.whonix.org/wiki/Upgrading_Whonix_13_to_Whonix_14). For a complete list of TemplateVM versions supported for your
specific version of Qubes, see Supported TemplateVM Versions (https://www.qubes-os.org/doc/supported-versions/#templatevms).
We also provide a fresh Whonix 14 TemplateVM package through the Qubes
repositories, which you can install in dom0 by following the Whonix
installation guide (https://www.whonix.org/wiki/Qubes/Install). If you encounter any difficulties when attempting to
upgrade or install Whonix templates, please consult the Whonix Support page (https://www.whonix.org/wiki/Support).
After upgrading your TemplateVMs, please remember to set all qubes that were
using the old template to use the new one. There are instructions to do this for
Qubes 3.2 (https://www.qubes-os.org/doc/templates/#how-to-switch-templates-32) and Qubes 4.0 (https://www.qubes-os.org/doc/templates/#how-to-switch-templates-40).
If you’re using an older version of Qubes than 3.2, we strongly recommend that
you upgrade to 3.2, as older versions are no longer supported.
https://www.qubes-os.org/news/2018/08/24/whonix-13-approaching-eol/
With the recent release of Whonix 14 (https://www.qubes-os.org/news/2018/08/07/whonix-14-has-been-released/), Whonix 13 will reach EOL (end-of-life)
on 2018-09-30. We strongly recommend that all Qubes users who have Whonix
TemplateVMs (https://www.qubes-os.org/doc/whonix/) or StandaloneVMs (https://www.qubes-os.org/doc/glossary/#standalonevm) upgrade them to Whonix 14 by 2018-09-30. The
Whonix Project (https://www.whonix.org/) provides step-by-step upgrade instructions for upgrading from
Whonix 13 to 14 (https://www.whonix.org/wiki/Upgrading_Whonix_13_to_Whonix_14). For a complete list of TemplateVM versions supported for your
specific version of Qubes, see Supported TemplateVM Versions (https://www.qubes-os.org/doc/supported-versions/#templatevms).
We also provide a fresh Whonix 14 TemplateVM package through the Qubes
repositories, which you can install in dom0 by following the Whonix
installation guide (https://www.whonix.org/wiki/Qubes/Install). If you encounter any difficulties when attempting to
upgrade or install Whonix templates, please consult the Whonix Support page (https://www.whonix.org/wiki/Support).
After upgrading your TemplateVMs, please remember to set all qubes that were
using the old template to use the new one. There are instructions to do this for
Qubes 3.2 (https://www.qubes-os.org/doc/templates/#how-to-switch-templates-32) and Qubes 4.0 (https://www.qubes-os.org/doc/templates/#how-to-switch-templates-40).
If you’re using an older version of Qubes than 3.2, we strongly recommend that
you upgrade to 3.2, as older versions are no longer supported.
QSB #43: L1 Terminal Fault speculative side channel (XSA-273)
https://www.qubes-os.org/news/2018/09/02/qsb-43/
Dear Qubes Community,
We have just published Qubes Security Bulletin (QSB) #43: L1 Terminal
Fault speculative side channel (XSA-273). 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 #43 in the qubes-secpack:
https://github.com/QubesOS/qubes-secpack/blob/master/QSBs/qsb-043-2018.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-273 in the XSA Tracker:
https://www.qubes-os.org/security/xsa/#273
---===[ Qubes Security Bulletin #43 ]===---
2018-09-02
L1 Terminal Fault speculative side channel (XSA-273)
Summary
========
On 2018-08-14, the Xen Security Team published Xen Security Advisory
273 (CVE-2018-3620,CVE-2018-3646 / XSA-273) [1] with the following
denoscription:
| In x86 nomenclature, a Terminal Fault is a pagetable walk which aborts
| due to the page being not present (e.g. paged out to disk), or because
| of reserved bits being set.
|
| Architecturally, such a memory access will result in a page fault
| exception, but some processors will speculatively compute the physical
| address and issue an L1D lookup. If data resides in the L1D cache, it
| may be forwarded to dependent instructions, and may be leaked via a side
| channel.
|
| Furthermore:
| * SGX protections are not applied
| * EPT guest to host translations are not applied
| * SMM protections are not applied
|
| This issue is split into multiple CVEs depending on circumstance. The
| CVEs which apply to Xen are:
| * CVE-2018-3620 - Operating Systems and SMM
| * CVE-2018-3646 - Hypervisors
|
| For more details, see:
| https://www.intel.com/content/www/us/en/security-center/advisory/intel-sa-00161.html
|
| An attacker can potentially read arbitrary host RAM. This includes data
| belonging to Xen, data belonging to other guests, and data belonging to
| different security contexts within the same guest.
|
| An attacker could be a guest kernel (which can manipulate the pagetables
| directly), or could be guest userspace either directly (e.g. with
| mprotect() or similar system call) or indirectly (by gaming the guest
| kernel's paging subsystem).
This is yet another CPU hardware bug related to speculative execution.
Only Intel processors are affected.
Impact of mitigations on Qubes OS
==================================
Qubes OS 3.2
-------------
Part of the mitigation is to disable hyper-threading. This halves the
number of CPU cores that the system sees compared to having
hyper-threading enabled, thus reducing system performance. This
mitigation is needed only when running HVM qubes (or PVH, but PVH is not
available in Qubes OS 3.2 anyway). However, we believe there is a risk
that similar issues will be discovered in the future, and that having
hyper-threading disabled may mitigate those issues, as it does this one.
Therefore, we recommend that most users leave hyper-threading disabled
regardless of whether they use HVM qubes.
If you decide that you are willing to accept the risks of enabling
hyper-threading, you can do so by following the instructions below. The
instructions differ depending on whether you use EFI or legacy boot.
How to re-enable hyper-threading with EFI boot:
1. Change `smt=off` to `smt=on` in `/boot/efi/EFI/qubes/xen.cfg` in dom0.
2. Save your change to the file.
3. Reboot dom0.
How to re-enable hyper-threading with legacy boot:
1. Change `smt=off` to `smt=on` in `/etc/default/grub` in dom0.
2. Save your change to the file.
3. Run `sudo grub2-mkconfig -o /boot/grub2/grub.cfg` in dom0.
4. Reboot dom0.
Qubes OS 4.0
-------------
https://www.qubes-os.org/news/2018/09/02/qsb-43/
Dear Qubes Community,
We have just published Qubes Security Bulletin (QSB) #43: L1 Terminal
Fault speculative side channel (XSA-273). 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 #43 in the qubes-secpack:
https://github.com/QubesOS/qubes-secpack/blob/master/QSBs/qsb-043-2018.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-273 in the XSA Tracker:
https://www.qubes-os.org/security/xsa/#273
---===[ Qubes Security Bulletin #43 ]===---
2018-09-02
L1 Terminal Fault speculative side channel (XSA-273)
Summary
========
On 2018-08-14, the Xen Security Team published Xen Security Advisory
273 (CVE-2018-3620,CVE-2018-3646 / XSA-273) [1] with the following
denoscription:
| In x86 nomenclature, a Terminal Fault is a pagetable walk which aborts
| due to the page being not present (e.g. paged out to disk), or because
| of reserved bits being set.
|
| Architecturally, such a memory access will result in a page fault
| exception, but some processors will speculatively compute the physical
| address and issue an L1D lookup. If data resides in the L1D cache, it
| may be forwarded to dependent instructions, and may be leaked via a side
| channel.
|
| Furthermore:
| * SGX protections are not applied
| * EPT guest to host translations are not applied
| * SMM protections are not applied
|
| This issue is split into multiple CVEs depending on circumstance. The
| CVEs which apply to Xen are:
| * CVE-2018-3620 - Operating Systems and SMM
| * CVE-2018-3646 - Hypervisors
|
| For more details, see:
| https://www.intel.com/content/www/us/en/security-center/advisory/intel-sa-00161.html
|
| An attacker can potentially read arbitrary host RAM. This includes data
| belonging to Xen, data belonging to other guests, and data belonging to
| different security contexts within the same guest.
|
| An attacker could be a guest kernel (which can manipulate the pagetables
| directly), or could be guest userspace either directly (e.g. with
| mprotect() or similar system call) or indirectly (by gaming the guest
| kernel's paging subsystem).
This is yet another CPU hardware bug related to speculative execution.
Only Intel processors are affected.
Impact of mitigations on Qubes OS
==================================
Qubes OS 3.2
-------------
Part of the mitigation is to disable hyper-threading. This halves the
number of CPU cores that the system sees compared to having
hyper-threading enabled, thus reducing system performance. This
mitigation is needed only when running HVM qubes (or PVH, but PVH is not
available in Qubes OS 3.2 anyway). However, we believe there is a risk
that similar issues will be discovered in the future, and that having
hyper-threading disabled may mitigate those issues, as it does this one.
Therefore, we recommend that most users leave hyper-threading disabled
regardless of whether they use HVM qubes.
If you decide that you are willing to accept the risks of enabling
hyper-threading, you can do so by following the instructions below. The
instructions differ depending on whether you use EFI or legacy boot.
How to re-enable hyper-threading with EFI boot:
1. Change `smt=off` to `smt=on` in `/boot/efi/EFI/qubes/xen.cfg` in dom0.
2. Save your change to the file.
3. Reboot dom0.
How to re-enable hyper-threading with legacy boot:
1. Change `smt=off` to `smt=on` in `/etc/default/grub` in dom0.
2. Save your change to the file.
3. Run `sudo grub2-mkconfig -o /boot/grub2/grub.cfg` in dom0.
4. Reboot dom0.
Qubes OS 4.0
-------------
Part of the mitigation is to disable hyper-threading. This halves the
number of CPU cores that the system sees compared to having
hyper-threading enabled, thus reducing system performance. Since Qubes
OS 4.0 uses both PVH and HVM qubes, it is _not_ safe to re-enable
hyper-threading. If you have previously modified the number of virtual
CPUs assigned to any qube (the "vcpus" property), it may be necessary to
adjust this value in order to account for reduced system performance.
In addition, if you use any PV qubes (which is discouraged for security
reasons), it is necessary to update their kernels to a version that
contains L1TF mitigations. Otherwise, they may crash when using swap,
which is part of the L1TF mitigation and (partially) due to the
intentional [2] lack of shadow paging support in Qubes OS 4.0. If the
kernel is provided by dom0 (the "kernel" property), we provide updated
kernel packages (see the "Patching" section below). If the kernel is
used from within the VM (using pvgrub), use the VM's appropriate
distribution update channel. Alternatively, to avoid crashing, you can
disable swap in such VMs.
Patching
=========
The Xen Project has provided patches that mitigate this issue. A CPU
microcode update is required to take advantage of them.
The specific packages that resolve the problems discussed in this
bulletin are as follows:
For Qubes 3.2:
- Xen packages, version 4.6.6-44
- microcode_ctl package, version 2.1-26.qubes1
- kernel-qubes-vm package, version 4.14.67-1
For Qubes 4.0:
- Xen packages, version 4.8.4-2
- microcode_ctl 2.1-26.qubes1
- kernel-qubes-vm package, version 4.14.67-1 (optional)
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-273.html
[2] https://www.qubes-os.org/news/2016/07/21/new-hw-certification-for-q4/
--
The Qubes Security Team
https://www.qubes-os.org/security/
number of CPU cores that the system sees compared to having
hyper-threading enabled, thus reducing system performance. Since Qubes
OS 4.0 uses both PVH and HVM qubes, it is _not_ safe to re-enable
hyper-threading. If you have previously modified the number of virtual
CPUs assigned to any qube (the "vcpus" property), it may be necessary to
adjust this value in order to account for reduced system performance.
In addition, if you use any PV qubes (which is discouraged for security
reasons), it is necessary to update their kernels to a version that
contains L1TF mitigations. Otherwise, they may crash when using swap,
which is part of the L1TF mitigation and (partially) due to the
intentional [2] lack of shadow paging support in Qubes OS 4.0. If the
kernel is provided by dom0 (the "kernel" property), we provide updated
kernel packages (see the "Patching" section below). If the kernel is
used from within the VM (using pvgrub), use the VM's appropriate
distribution update channel. Alternatively, to avoid crashing, you can
disable swap in such VMs.
Patching
=========
The Xen Project has provided patches that mitigate this issue. A CPU
microcode update is required to take advantage of them.
The specific packages that resolve the problems discussed in this
bulletin are as follows:
For Qubes 3.2:
- Xen packages, version 4.6.6-44
- microcode_ctl package, version 2.1-26.qubes1
- kernel-qubes-vm package, version 4.14.67-1
For Qubes 4.0:
- Xen packages, version 4.8.4-2
- microcode_ctl 2.1-26.qubes1
- kernel-qubes-vm package, version 4.14.67-1 (optional)
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-273.html
[2] https://www.qubes-os.org/news/2016/07/21/new-hw-certification-for-q4/
--
The Qubes Security Team
https://www.qubes-os.org/security/
TinyVMI: Porting LibVMI to Mini-OS on Xen Project Hypervisor
https://blog.xenproject.org/2018/09/05/tinyvmi-porting-libvmi-to-mini-os-on-xen-project-hypervisor/
This blog post comes from Lele Ma, a Ph.D. student at William and Mary. He was recently a Google Summer of Code Intern working on the Honeynet Project. Introduction This post introduces the project I worked on with Honeynet Project at Google Summer of Code this year. The project of TinyVMI is to port a […]
https://blog.xenproject.org/2018/09/05/tinyvmi-porting-libvmi-to-mini-os-on-xen-project-hypervisor/
This blog post comes from Lele Ma, a Ph.D. student at William and Mary. He was recently a Google Summer of Code Intern working on the Honeynet Project. Introduction This post introduces the project I worked on with Honeynet Project at Google Summer of Code this year. The project of TinyVMI is to port a […]
Introducing the Qubes U2F Proxy
https://www.qubes-os.org/news/2018/09/11/qubes-u2f-proxy/
Today we’d like to announce the Qubes U2F Proxy (https://github.com/QubesOS/qubes-app-u2f). It is a secure proxy intended
to make use of U2F two-factor authentication devices with web browsers without
exposing the browser to the full USB stack, not unlike the USB keyboard and
mouse proxies (https://www.qubes-os.org/doc/usb/) we’ve already implemented in Qubes.
What is U2F?
U2F (https://en.wikipedia.org/wiki/U2F), which stands for “Universal 2nd Factor”, is a framework for
authentication using hardware devices (U2F tokens) as “second factors”, i.e.
what you have as opposed to what you know, like a passphrase. This
additional control provides good protection (https://krebsonsecurity.com/2018/07/google-security-keys-neutralized-employee-phishing/) in cases in which the
passphrase is stolen (e.g. by phishing or keylogging). While passphrase
compromise may not be obvious to the user, a physical device that cannot be
duplicated must be stolen to be used outside of the owner’s control.
Nonetheless, it is important to note at the outset that U2F cannot guarantee
security when the host system is compromised (e.g. a malware-infected operating
system under an adversary’s control).
The U2F specification defines protocols for multiple layers from USB to the
browser API, and the whole stack is intended to be used with web applications
(most commonly websites) in browsers. In most cases, tokens are USB dongles.
The protocol is very simple, allowing the devices to store very little state
inside (so the tokens may be reasonably cheap) while simultaneously
authenticating a virtually unlimited number of services (so each person needs
only one token, not one token per application). The user interface is usually
limited to a single LED and a button that is pressed to confirm each
transaction, so the devices themselves are also easy to use.
Currently, the most common form of two-step authentication consists of a numeric
code that the user manually types into a web application. These codes are
typically generated by an app on the user’s smartphone or sent via SMS. By now,
it is well-known that this form of two-step authentication is vulnerable to
phishing and man-in-the-middle attacks due to the fact that the application
requesting the two-step authentication code is typically not itself
authenticated by the user. (In other words, users can accidentally give their
codes to attackers because they do not always know who is really requesting the
code.) In the U2F model, by contrast, the browser ensures that the token
receives valid information about the web application requesting authentication,
so the token knows which application it is authenticating (for details, see
here (https://fidoalliance.org/specs/fido-u2f-v1.2-ps-20170411/fido-u2f-overview-v1.2-ps-20170411.html#site-specific-public-private-key-pairs)). Nonetheless, some attacks are still possible (https://www.wired.com/story/chrome-yubikey-phishing-webusb/) even
with U2F (more on this below).
Our take on U2F
In a conventional setup, web browsers and the USB stack (to which the U2F token
is connected) are all running in the same monolithic OS. Since the U2F model
assumes that the browser is trustworthy, any browser in the OS is able to access
any key stored on the U2F token. The user has no way to know which keys have
been accessed by which browsers for which services. If any of the browsers are
compromised, it should be assumed that all of the token’s keys have been
compromised. (This problem can be mitigated, however, if the U2F device has a
special display to show the user what’s being authenticated.) Moreover, since
the USB stack is in the same monolithic OS, the system is vulnerable to attacks
like BadUSB (https://www.blackhat.com/us-14/briefings.html#badusb-on-accessories-that-turn-evil).
In Qubes OS, by contrast, it is possible to securely compartmentalise the
https://www.qubes-os.org/news/2018/09/11/qubes-u2f-proxy/
Today we’d like to announce the Qubes U2F Proxy (https://github.com/QubesOS/qubes-app-u2f). It is a secure proxy intended
to make use of U2F two-factor authentication devices with web browsers without
exposing the browser to the full USB stack, not unlike the USB keyboard and
mouse proxies (https://www.qubes-os.org/doc/usb/) we’ve already implemented in Qubes.
What is U2F?
U2F (https://en.wikipedia.org/wiki/U2F), which stands for “Universal 2nd Factor”, is a framework for
authentication using hardware devices (U2F tokens) as “second factors”, i.e.
what you have as opposed to what you know, like a passphrase. This
additional control provides good protection (https://krebsonsecurity.com/2018/07/google-security-keys-neutralized-employee-phishing/) in cases in which the
passphrase is stolen (e.g. by phishing or keylogging). While passphrase
compromise may not be obvious to the user, a physical device that cannot be
duplicated must be stolen to be used outside of the owner’s control.
Nonetheless, it is important to note at the outset that U2F cannot guarantee
security when the host system is compromised (e.g. a malware-infected operating
system under an adversary’s control).
The U2F specification defines protocols for multiple layers from USB to the
browser API, and the whole stack is intended to be used with web applications
(most commonly websites) in browsers. In most cases, tokens are USB dongles.
The protocol is very simple, allowing the devices to store very little state
inside (so the tokens may be reasonably cheap) while simultaneously
authenticating a virtually unlimited number of services (so each person needs
only one token, not one token per application). The user interface is usually
limited to a single LED and a button that is pressed to confirm each
transaction, so the devices themselves are also easy to use.
Currently, the most common form of two-step authentication consists of a numeric
code that the user manually types into a web application. These codes are
typically generated by an app on the user’s smartphone or sent via SMS. By now,
it is well-known that this form of two-step authentication is vulnerable to
phishing and man-in-the-middle attacks due to the fact that the application
requesting the two-step authentication code is typically not itself
authenticated by the user. (In other words, users can accidentally give their
codes to attackers because they do not always know who is really requesting the
code.) In the U2F model, by contrast, the browser ensures that the token
receives valid information about the web application requesting authentication,
so the token knows which application it is authenticating (for details, see
here (https://fidoalliance.org/specs/fido-u2f-v1.2-ps-20170411/fido-u2f-overview-v1.2-ps-20170411.html#site-specific-public-private-key-pairs)). Nonetheless, some attacks are still possible (https://www.wired.com/story/chrome-yubikey-phishing-webusb/) even
with U2F (more on this below).
Our take on U2F
In a conventional setup, web browsers and the USB stack (to which the U2F token
is connected) are all running in the same monolithic OS. Since the U2F model
assumes that the browser is trustworthy, any browser in the OS is able to access
any key stored on the U2F token. The user has no way to know which keys have
been accessed by which browsers for which services. If any of the browsers are
compromised, it should be assumed that all of the token’s keys have been
compromised. (This problem can be mitigated, however, if the U2F device has a
special display to show the user what’s being authenticated.) Moreover, since
the USB stack is in the same monolithic OS, the system is vulnerable to attacks
like BadUSB (https://www.blackhat.com/us-14/briefings.html#badusb-on-accessories-that-turn-evil).
In Qubes OS, by contrast, it is possible to securely compartmentalise the
browser in one qube and the USB stack in another so that they are always kept
separate from each other. The Qubes U2F Proxy then allows the token connected to
the USB stack in one qube to communicate with the browser in a separate qube. We
operate under the assumption that the USB stack is untrusted from the point of
view of the browser and also that the browser is not to be trusted blindly by
the token. Therefore, the token is never in the same qube as the browser. Our
proxy forwards only the data necessary to actually perform the authentication,
leaving all unnecessary data out, so it won’t become a vector of attack. This is
depicted in the diagram below (click for full size).
separate from each other. The Qubes U2F Proxy then allows the token connected to
the USB stack in one qube to communicate with the browser in a separate qube. We
operate under the assumption that the USB stack is untrusted from the point of
view of the browser and also that the browser is not to be trusted blindly by
the token. Therefore, the token is never in the same qube as the browser. Our
proxy forwards only the data necessary to actually perform the authentication,
leaving all unnecessary data out, so it won’t become a vector of attack. This is
depicted in the diagram below (click for full size).
The Qubes U2F Proxy has two parts: the frontend and the backend. The frontend
runs in the same qube as the browser and presents a fake USB-like HID device
using uhid. The backend runs in sys-usb and behaves like a browser. This is
done using the u2flib_host reference library. All of our code was written in
Python. The standard qrexec (https://www.qubes-os.org/doc/qrexec3/) policy is responsible for directing calls to the
appropriate domains.
The vault qube with a dashed line in the bottom portion of the diagram depicts
future work in which we plan to implement the Qubes U2F Proxy with a software
token in an isolated qube rather than a physical hardware token. This is similar
to the manner in which Split GPG (https://www.qubes-os.org/doc/split-gpg/) allows us to emulate the smart card model
without physical smart cards.
One very important assumption of U2F is that the browser verifies every request
sent to the U2F token — in particular, that the web application sending an
authentication request matches the application that would be authenticated by
answering that request (in order to prevent, e.g., a phishing site from sending
an authentication request for your bank’s site). With the WebUSB feature in
Chrome, however, a malicious website can bypass (https://www.wired.com/story/chrome-yubikey-phishing-webusb/) this safeguard by
connecting directly to the token instead of using the browser’s U2F API.
The Qubes U2F Proxy also prevents this class of attacks by implementing an
additional verification layer. This verification layer allows you to enforce,
for example, that the web browser in your twitter qube can only access the U2F
key associated with https://twitter.com. This means that if anything in your
twitter qube were compromised — the browser or even the OS itself — it
would still not be able to access the U2F keys on your token for any other
websites or services, like your email and bank accounts. This is another
significant security advantage over monolithic systems. (For details and
instructions, see the Advanced usage (https://www.qubes-os.org/#advanced-usage-per-qube-key-access) section below.)
For even more protection, you can combine this with the Qubes firewall (https://www.qubes-os.org/doc/firewall/) to
ensure, for example, that the browser in your banking qube accesses only one
website (your bank’s website). By configuring the Qubes firewall to prevent your
banking qube from accessing any other websites, you reduce the risk of another
website compromising the browser in an attempt to bypass U2F authentication.
Installation
The Qubes U2F Proxy tool can be installed in Qubes 3.2 and 4.0. (However, the
Advanced usage (https://www.qubes-os.org/#advanced-usage-per-qube-key-access) features are only available in 4.0.) These instructions assume
that there is a sys-usb qube that holds the USB stack, which is the default
configuration in most Qubes OS installations.
In dom0:
$ sudo qubes-dom0-update qubes-u2f-dom0
$ qvm-service --enable work qubes-u2f-proxy
In Fedora TemplateVMs:
$ sudo dnf install qubes-u2f
In Debian TemplateVMs:
$ sudo apt install qubes-u2f
Repeat qvm-service --enable (or do this in VM settings -> Services in the Qube
Manager) for all qubes that should have the proxy enabled. As usual with
software updates, shut down the templates after installation, then restart
sys-usb and all qubes that use the proxy. After that, you may use your U2F
token (but see Browser support (https://www.qubes-os.org/#templatevm-and-browser-support) below).
Advanced usage: per-qube key access
If you are using Qubes 4.0, you can further compartmentalise your U2F keys by
restricting each qube’s access to specific keys. For example, you could make it
so that your twitter qube (and, therefore, all web browsers in your twitter
qube) can access only the key on your U2F token for https://twitter.com,
regardless of whether any of the web browsers in your twitter qube or the
runs in the same qube as the browser and presents a fake USB-like HID device
using uhid. The backend runs in sys-usb and behaves like a browser. This is
done using the u2flib_host reference library. All of our code was written in
Python. The standard qrexec (https://www.qubes-os.org/doc/qrexec3/) policy is responsible for directing calls to the
appropriate domains.
The vault qube with a dashed line in the bottom portion of the diagram depicts
future work in which we plan to implement the Qubes U2F Proxy with a software
token in an isolated qube rather than a physical hardware token. This is similar
to the manner in which Split GPG (https://www.qubes-os.org/doc/split-gpg/) allows us to emulate the smart card model
without physical smart cards.
One very important assumption of U2F is that the browser verifies every request
sent to the U2F token — in particular, that the web application sending an
authentication request matches the application that would be authenticated by
answering that request (in order to prevent, e.g., a phishing site from sending
an authentication request for your bank’s site). With the WebUSB feature in
Chrome, however, a malicious website can bypass (https://www.wired.com/story/chrome-yubikey-phishing-webusb/) this safeguard by
connecting directly to the token instead of using the browser’s U2F API.
The Qubes U2F Proxy also prevents this class of attacks by implementing an
additional verification layer. This verification layer allows you to enforce,
for example, that the web browser in your twitter qube can only access the U2F
key associated with https://twitter.com. This means that if anything in your
twitter qube were compromised — the browser or even the OS itself — it
would still not be able to access the U2F keys on your token for any other
websites or services, like your email and bank accounts. This is another
significant security advantage over monolithic systems. (For details and
instructions, see the Advanced usage (https://www.qubes-os.org/#advanced-usage-per-qube-key-access) section below.)
For even more protection, you can combine this with the Qubes firewall (https://www.qubes-os.org/doc/firewall/) to
ensure, for example, that the browser in your banking qube accesses only one
website (your bank’s website). By configuring the Qubes firewall to prevent your
banking qube from accessing any other websites, you reduce the risk of another
website compromising the browser in an attempt to bypass U2F authentication.
Installation
The Qubes U2F Proxy tool can be installed in Qubes 3.2 and 4.0. (However, the
Advanced usage (https://www.qubes-os.org/#advanced-usage-per-qube-key-access) features are only available in 4.0.) These instructions assume
that there is a sys-usb qube that holds the USB stack, which is the default
configuration in most Qubes OS installations.
In dom0:
$ sudo qubes-dom0-update qubes-u2f-dom0
$ qvm-service --enable work qubes-u2f-proxy
In Fedora TemplateVMs:
$ sudo dnf install qubes-u2f
In Debian TemplateVMs:
$ sudo apt install qubes-u2f
Repeat qvm-service --enable (or do this in VM settings -> Services in the Qube
Manager) for all qubes that should have the proxy enabled. As usual with
software updates, shut down the templates after installation, then restart
sys-usb and all qubes that use the proxy. After that, you may use your U2F
token (but see Browser support (https://www.qubes-os.org/#templatevm-and-browser-support) below).
Advanced usage: per-qube key access
If you are using Qubes 4.0, you can further compartmentalise your U2F keys by
restricting each qube’s access to specific keys. For example, you could make it
so that your twitter qube (and, therefore, all web browsers in your twitter
qube) can access only the key on your U2F token for https://twitter.com,
regardless of whether any of the web browsers in your twitter qube or the