Qubes Canary #15
https://www.qubes-os.org/news/2018/03/15/canary-15/
Dear Qubes Community,
We have published Qubes Canary #15. The text of this canary is
reproduced below. This canary and its accompanying signatures will always be
available in the Qubes Security Pack (qubes-secpack).
View Qubes Canary #15 in the qubes-secpack:
https://github.com/QubesOS/qubes-secpack/blob/master/canaries/canary-015-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 canaries:
https://www.qubes-os.org/security/canaries/
---===[ Qubes Canary #15 ]===---
Statements
-----------
The Qubes core developers who have digitally signed this file [1]
state the following:
1. The date of issue of this canary is March 14, 2018.
2. There have been 38 Qubes Security Bulletins published so far.
3. The Qubes Master Signing Key fingerprint is:
427F 11FD 0FAA 4B08 0123 F01C DDFA 1A3E 3687 9494
4. No warrants have ever been served to us with regard to the Qubes OS
Project (e.g. to hand out the private signing keys or to introduce
backdoors).
5. We plan to publish the next of these canary statements in the first
two weeks of June 2018. Special note should be taken if no new canary
is published by that time or if the list of statements changes without
plausible explanation.
Special announcements
----------------------
None.
Disclaimers and notes
----------------------
We would like to remind you that Qubes OS has been designed under the
assumption that all relevant infrastructure is permanently
compromised. This means that we assume NO trust in any of the servers
or services which host or provide any Qubes-related data, in
particular, software updates, source code repositories, and Qubes ISO
downloads.
This canary scheme is not infallible. Although signing the declaration
makes it very difficult for a third party to produce arbitrary
declarations, it does not prevent them from using force or other
means, like blackmail or compromising the signers' laptops, to coerce
us to produce false declarations.
The news feeds quoted below (Proof of freshness) serves to demonstrate
that this canary could not have been created prior to the date stated.
It shows that a series of canaries was not created in advance.
This declaration is merely a best effort and is provided without any
guarantee or warranty. It is not legally binding in any way to
anybody. None of the signers should be ever held legally responsible
for any of the statements made here.
Proof of freshness
-------------------
$ date -R -u
Wed, 14 Mar 2018 13:38:04 +0000
$ feedstail -1 -n5 -f '{noscript}' -u https://www.spiegel.de/international/index.rss
Refugee Bedtime Stories: 'A Long, Long Time Ago, Syria Was Beautiful, My Son'
Creative Destruction: Macron Eyes Expanding His Movement Across Europe
'The Sale of Our Identity': C&A Family Member Discusses Firm's Uncertain Future
The Trade Warrior: Donald Trump's Attack on German Prosperity
Reporter Podcast: Understanding the Riddles of Greenland
$ feedstail -1 -n5 -f '{noscript}' -u https://rss.nytimes.com/services/xml/rss/nyt/World.xml
Why Moscow Will Never Apologize for Attack on Ex-Spy
The Biggest Refugee Camp Braces for Rain: ‘This Is Going to Be a Catastrophe’
Tillerson’s Firing Had Been Expected, but It Still Stunned Observers
Now Two Former Presidents of South Korea Are Under Investigation
New Zealand Diplomat Censured for Vulgar Tweet About U.S. Democrats
$ feedstail -1 -n5 -f '{noscript}' -u https://feeds.bbci.co.uk/news/world/rss.xml
Stephen Hawking: Visionary physicist dies aged 76
Democrat Conor Lamb claims victory in Pennsylvania election
Rex Tillerson: Secretary of state fired by Trump in Russia warning
Italy bomb: World War Two device forces mass evacuation in Fano
Caribbean volcano Kick 'em Jenny: Ships warned off area
$ feedstail -1 -n5 -f '{noscript}' -u http://feeds.reuters.com/reuters/worldnews
https://www.qubes-os.org/news/2018/03/15/canary-15/
Dear Qubes Community,
We have published Qubes Canary #15. The text of this canary is
reproduced below. This canary and its accompanying signatures will always be
available in the Qubes Security Pack (qubes-secpack).
View Qubes Canary #15 in the qubes-secpack:
https://github.com/QubesOS/qubes-secpack/blob/master/canaries/canary-015-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 canaries:
https://www.qubes-os.org/security/canaries/
---===[ Qubes Canary #15 ]===---
Statements
-----------
The Qubes core developers who have digitally signed this file [1]
state the following:
1. The date of issue of this canary is March 14, 2018.
2. There have been 38 Qubes Security Bulletins published so far.
3. The Qubes Master Signing Key fingerprint is:
427F 11FD 0FAA 4B08 0123 F01C DDFA 1A3E 3687 9494
4. No warrants have ever been served to us with regard to the Qubes OS
Project (e.g. to hand out the private signing keys or to introduce
backdoors).
5. We plan to publish the next of these canary statements in the first
two weeks of June 2018. Special note should be taken if no new canary
is published by that time or if the list of statements changes without
plausible explanation.
Special announcements
----------------------
None.
Disclaimers and notes
----------------------
We would like to remind you that Qubes OS has been designed under the
assumption that all relevant infrastructure is permanently
compromised. This means that we assume NO trust in any of the servers
or services which host or provide any Qubes-related data, in
particular, software updates, source code repositories, and Qubes ISO
downloads.
This canary scheme is not infallible. Although signing the declaration
makes it very difficult for a third party to produce arbitrary
declarations, it does not prevent them from using force or other
means, like blackmail or compromising the signers' laptops, to coerce
us to produce false declarations.
The news feeds quoted below (Proof of freshness) serves to demonstrate
that this canary could not have been created prior to the date stated.
It shows that a series of canaries was not created in advance.
This declaration is merely a best effort and is provided without any
guarantee or warranty. It is not legally binding in any way to
anybody. None of the signers should be ever held legally responsible
for any of the statements made here.
Proof of freshness
-------------------
$ date -R -u
Wed, 14 Mar 2018 13:38:04 +0000
$ feedstail -1 -n5 -f '{noscript}' -u https://www.spiegel.de/international/index.rss
Refugee Bedtime Stories: 'A Long, Long Time Ago, Syria Was Beautiful, My Son'
Creative Destruction: Macron Eyes Expanding His Movement Across Europe
'The Sale of Our Identity': C&A Family Member Discusses Firm's Uncertain Future
The Trade Warrior: Donald Trump's Attack on German Prosperity
Reporter Podcast: Understanding the Riddles of Greenland
$ feedstail -1 -n5 -f '{noscript}' -u https://rss.nytimes.com/services/xml/rss/nyt/World.xml
Why Moscow Will Never Apologize for Attack on Ex-Spy
The Biggest Refugee Camp Braces for Rain: ‘This Is Going to Be a Catastrophe’
Tillerson’s Firing Had Been Expected, but It Still Stunned Observers
Now Two Former Presidents of South Korea Are Under Investigation
New Zealand Diplomat Censured for Vulgar Tweet About U.S. Democrats
$ feedstail -1 -n5 -f '{noscript}' -u https://feeds.bbci.co.uk/news/world/rss.xml
Stephen Hawking: Visionary physicist dies aged 76
Democrat Conor Lamb claims victory in Pennsylvania election
Rex Tillerson: Secretary of state fired by Trump in Russia warning
Italy bomb: World War Two device forces mass evacuation in Fano
Caribbean volcano Kick 'em Jenny: Ships warned off area
$ feedstail -1 -n5 -f '{noscript}' -u http://feeds.reuters.com/reuters/worldnews
Britain expels 23 Russian diplomats over chemical attack on ex-spy
Stephen Hawking, who unlocked the secrets of space and time, dies at 76
Turkey's Erdogan says hopes Syria's Afrin town to be captured by Wednesday evening
Civilians needing medical aid leave Syria's Ghouta for second day
Tokyo bids farewell to 'trustworthy' Tillerson, Seoul awaits seasoned Pompeo
$ curl -s 'https://blockchain.info/blocks/?format=json'
$ python3 -c 'import sys, json; print(json.load(sys.stdin)['\''blocks'\''][10]['\''hash'\''])'
00000000000000000020436a19f4772283e739a4dbd171be51214f5fe73c6804
Footnotes
----------
[1] This file should be signed in two ways: (1) via detached PGP
signatures by each of the signers, distributed together with this
canary in the qubes-secpack.git repo, and (2) via digital signatures
on the corresponding qubes-secpack.git repo tags. [2]
[2] Don't just trust the contents of this file blindly! Verify the
digital signatures!
Stephen Hawking, who unlocked the secrets of space and time, dies at 76
Turkey's Erdogan says hopes Syria's Afrin town to be captured by Wednesday evening
Civilians needing medical aid leave Syria's Ghouta for second day
Tokyo bids farewell to 'trustworthy' Tillerson, Seoul awaits seasoned Pompeo
$ curl -s 'https://blockchain.info/blocks/?format=json'
$ python3 -c 'import sys, json; print(json.load(sys.stdin)['\''blocks'\''][10]['\''hash'\''])'
00000000000000000020436a19f4772283e739a4dbd171be51214f5fe73c6804
Footnotes
----------
[1] This file should be signed in two ways: (1) via detached PGP
signatures by each of the signers, distributed together with this
canary in the qubes-secpack.git repo, and (2) via digital signatures
on the corresponding qubes-secpack.git repo tags. [2]
[2] Don't just trust the contents of this file blindly! Verify the
digital signatures!
Xen Project Contributor Spotlight: Yurii Konovalenko
https://blog.xenproject.org/2018/03/21/xen-project-contributor-spotlight-yurii-konovalenko/
The Xen Project is comprised of a diverse set of member companies and contributors that are committed to the growth and success of the Xen Project Hypervisor. The Xen Project Hypervisor is a staple technology for server and cloud vendors, and is gaining traction in the embedded, security and automotive space. This blog series highlights […]
https://blog.xenproject.org/2018/03/21/xen-project-contributor-spotlight-yurii-konovalenko/
The Xen Project is comprised of a diverse set of member companies and contributors that are committed to the growth and success of the Xen Project Hypervisor. The Xen Project Hypervisor is a staple technology for server and cloud vendors, and is gaining traction in the embedded, security and automotive space. This blog series highlights […]
Qubes OS 4.0 has been released!
https://www.qubes-os.org/news/2018/03/28/qubes-40/
After nearly two years in development and countless hours of testing,
we’re pleased to announce the stable release of Qubes OS 4.0!
Major changes in version 4.0
Version 4.0 includes several fundamental improvements to the security
and functionality of Qubes OS:
The Qubes Admin API (https://www.qubes-os.org/news/2017/06/27/qubes-admin-api/)
Qubes Core Stack version 3 (https://www.qubes-os.org/news/2017/10/03/core3/)
Fully virtualized VMs for enhanced security (https://github.com/QubesOS/qubes-secpack/blob/master/QSBs/qsb-037-2018.txt)
Multiple, flexible Disposable VM templates (https://github.com/QubesOS/qubes-issues/issues/2253)
A more expressive, user-friendly Qubes RPC policy
system (https://www.qubes-os.org/doc/qrexec3/#extra-keywords-available-in-qubes-40-and-later)
A powerful new VM volume manager that makes it easy to keep VMs on
external drives (https://github.com/QubesOS/qubes-issues/issues/1842)
Enhanced TemplateVM security via split packages (https://github.com/QubesOS/qubes-issues/issues/2771) and network
interface removal (https://github.com/QubesOS/qubes-issues/issues/1854)
More secure backups with scrypt for stronger key
derivation and enforced encryption
Rewritten command-line tools with new options (https://www.qubes-os.org/doc/tools/4.0/)
This release delivers on the features we promised in our announcement
of Qubes 4.0-rc1 (https://www.qubes-os.org/news/2017/07/31/qubes-40-rc1/), with some course corrections along the way,
such as the switch from HVM to PVH for most VMs in response to Meltdown
and Spectre (https://github.com/QubesOS/qubes-secpack/blob/master/QSBs/qsb-037-2018.txt). For more details, please see the full Release
Notes (https://www.qubes-os.org/doc/releases/4.0/release-notes/). The Qubes 4.0 installation image is available on the
Downloads (https://www.qubes-os.org/downloads/) page, along with the complete Installation Guide (https://www.qubes-os.org/doc/installation-guide/).
Current 4.0 release candidate users
In our Qubes 4.0-rc5 announcement (https://www.qubes-os.org/news/2018/03/06/qubes-40-rc5/), we explained that if the
testing of 4.0-rc5 did not reveal any major problems, we would declare
it to be the stable 4.0 release without any further significant changes
and that, in this scenario, any bugs discovered during the testing
process would be fixed in subsequent updates. This is, in fact, what has
occurred. We found that, with the fifth release candidate, 4.0 had
finally reached a level of stability that met our standards such that we
were comfortable designating it the stable release. Accordingly, current
users of 4.0-rc5 can upgrade in-place by downloading the latest updates
from the stable repositories in both dom0 (https://www.qubes-os.org/doc/software-update-dom0/#how-to-update-software-in-dom0) and TemplateVMs (https://www.qubes-os.org/doc/software-update-vm/#installing-or-updating-software-in-the-templatevm).
We know that this stable release has been a long time in coming for many
you. We sincerely appreciate your patience. Thank you for sticking with
us. We’re especially grateful to all of you who have contributed code (https://www.qubes-os.org/doc/contributing/#contributing-code)
and documentation (https://www.qubes-os.org/doc/doc-guidelines/) to this release, tested (https://www.qubes-os.org/doc/testing/) release candidates, and
diligently reported bugs (https://www.qubes-os.org/doc/reporting-bugs/). This stable release would not have been
possible without your efforts. Your involvement makes Qubes a truly
open-source project. Your energy, skill, and good will make this project
a joy to work on. We are lucky to have you.
The past and the future
Since first announcing extended support for Qubes 3.2 (https://www.qubes-os.org/news/2016/09/02/4-0-minimum-requirements-3-2-extended-support/#extended-support-for-qubes-os-32),
https://www.qubes-os.org/news/2018/03/28/qubes-40/
After nearly two years in development and countless hours of testing,
we’re pleased to announce the stable release of Qubes OS 4.0!
Major changes in version 4.0
Version 4.0 includes several fundamental improvements to the security
and functionality of Qubes OS:
The Qubes Admin API (https://www.qubes-os.org/news/2017/06/27/qubes-admin-api/)
Qubes Core Stack version 3 (https://www.qubes-os.org/news/2017/10/03/core3/)
Fully virtualized VMs for enhanced security (https://github.com/QubesOS/qubes-secpack/blob/master/QSBs/qsb-037-2018.txt)
Multiple, flexible Disposable VM templates (https://github.com/QubesOS/qubes-issues/issues/2253)
A more expressive, user-friendly Qubes RPC policy
system (https://www.qubes-os.org/doc/qrexec3/#extra-keywords-available-in-qubes-40-and-later)
A powerful new VM volume manager that makes it easy to keep VMs on
external drives (https://github.com/QubesOS/qubes-issues/issues/1842)
Enhanced TemplateVM security via split packages (https://github.com/QubesOS/qubes-issues/issues/2771) and network
interface removal (https://github.com/QubesOS/qubes-issues/issues/1854)
More secure backups with scrypt for stronger key
derivation and enforced encryption
Rewritten command-line tools with new options (https://www.qubes-os.org/doc/tools/4.0/)
This release delivers on the features we promised in our announcement
of Qubes 4.0-rc1 (https://www.qubes-os.org/news/2017/07/31/qubes-40-rc1/), with some course corrections along the way,
such as the switch from HVM to PVH for most VMs in response to Meltdown
and Spectre (https://github.com/QubesOS/qubes-secpack/blob/master/QSBs/qsb-037-2018.txt). For more details, please see the full Release
Notes (https://www.qubes-os.org/doc/releases/4.0/release-notes/). The Qubes 4.0 installation image is available on the
Downloads (https://www.qubes-os.org/downloads/) page, along with the complete Installation Guide (https://www.qubes-os.org/doc/installation-guide/).
Current 4.0 release candidate users
In our Qubes 4.0-rc5 announcement (https://www.qubes-os.org/news/2018/03/06/qubes-40-rc5/), we explained that if the
testing of 4.0-rc5 did not reveal any major problems, we would declare
it to be the stable 4.0 release without any further significant changes
and that, in this scenario, any bugs discovered during the testing
process would be fixed in subsequent updates. This is, in fact, what has
occurred. We found that, with the fifth release candidate, 4.0 had
finally reached a level of stability that met our standards such that we
were comfortable designating it the stable release. Accordingly, current
users of 4.0-rc5 can upgrade in-place by downloading the latest updates
from the stable repositories in both dom0 (https://www.qubes-os.org/doc/software-update-dom0/#how-to-update-software-in-dom0) and TemplateVMs (https://www.qubes-os.org/doc/software-update-vm/#installing-or-updating-software-in-the-templatevm).
We know that this stable release has been a long time in coming for many
you. We sincerely appreciate your patience. Thank you for sticking with
us. We’re especially grateful to all of you who have contributed code (https://www.qubes-os.org/doc/contributing/#contributing-code)
and documentation (https://www.qubes-os.org/doc/doc-guidelines/) to this release, tested (https://www.qubes-os.org/doc/testing/) release candidates, and
diligently reported bugs (https://www.qubes-os.org/doc/reporting-bugs/). This stable release would not have been
possible without your efforts. Your involvement makes Qubes a truly
open-source project. Your energy, skill, and good will make this project
a joy to work on. We are lucky to have you.
The past and the future
Since first announcing extended support for Qubes 3.2 (https://www.qubes-os.org/news/2016/09/02/4-0-minimum-requirements-3-2-extended-support/#extended-support-for-qubes-os-32),
we determined that users would be better served by having a version of
Qubes 3.2 with updated TemplateVMs and a newer kernel. We’ve designated
this release Qubes 3.2.1. As the name suggests, this is a point release
for Qubes 3.2 that does not contain any major changes, and it is this
release to which the extended support period will apply. We intend for
Qubes 3.2.1 to be a viable alternative to version 4.0 for those who wish
to use Qubes on hardware that does not meet the system requirements for
Qubes 4.0 (https://www.qubes-os.org/doc/system-requirements/#qubes-release-4x). While our standard policy (https://www.qubes-os.org/doc/supported-versions/#qubes-os) is to
support each Qubes release for six months after the next major or minor
release, the special extension for 3.2.1 raises this period to one full
year. Therefore, the stable release of Qubes 4.0 sets the EOL
(end-of-life) date for Qubes 3.2.1 at one year from today on 2019-03-28.
We expect 3.2.1 to be available soon, after Kernel 4.9 testing is
completed.
Looking forward, our work on Qubes 4.x has only just begun. Our sights
are now set on Qubes 4.1, for which we have a growing
list (https://github.com/QubesOS/qubes-issues/issues?q=is%3Aopen+is%3Aissue+milestone%3A%22Release+4.1%22+label%3Aenhancement) of planned enhancements to nearly every aspect
of Qubes OS. Whether you’re new to Qubes or have been here for years, we
welcome you to join us and get involved (https://www.qubes-os.org/doc/contributing/). We’ve
personally chosen to devote our time and skills to making Qubes freely
available to the world because we believe that being open-source is
essential to Qubes being trustworthy and secure. If Qubes is valuable to
you, we ask that you please consider making a donation (https://www.qubes-os.org/donate/) to the project.
With your support, we can continue to make reasonable security a reality
for many years to come.
Qubes 3.2 with updated TemplateVMs and a newer kernel. We’ve designated
this release Qubes 3.2.1. As the name suggests, this is a point release
for Qubes 3.2 that does not contain any major changes, and it is this
release to which the extended support period will apply. We intend for
Qubes 3.2.1 to be a viable alternative to version 4.0 for those who wish
to use Qubes on hardware that does not meet the system requirements for
Qubes 4.0 (https://www.qubes-os.org/doc/system-requirements/#qubes-release-4x). While our standard policy (https://www.qubes-os.org/doc/supported-versions/#qubes-os) is to
support each Qubes release for six months after the next major or minor
release, the special extension for 3.2.1 raises this period to one full
year. Therefore, the stable release of Qubes 4.0 sets the EOL
(end-of-life) date for Qubes 3.2.1 at one year from today on 2019-03-28.
We expect 3.2.1 to be available soon, after Kernel 4.9 testing is
completed.
Looking forward, our work on Qubes 4.x has only just begun. Our sights
are now set on Qubes 4.1, for which we have a growing
list (https://github.com/QubesOS/qubes-issues/issues?q=is%3Aopen+is%3Aissue+milestone%3A%22Release+4.1%22+label%3Aenhancement) of planned enhancements to nearly every aspect
of Qubes OS. Whether you’re new to Qubes or have been here for years, we
welcome you to join us and get involved (https://www.qubes-os.org/doc/contributing/). We’ve
personally chosen to devote our time and skills to making Qubes freely
available to the world because we believe that being open-source is
essential to Qubes being trustworthy and secure. If Qubes is valuable to
you, we ask that you please consider making a donation (https://www.qubes-os.org/donate/) to the project.
With your support, we can continue to make reasonable security a reality
for many years to come.
Join us at Root Linux Conference Happening in Kyiv, Ukraine This April!
https://blog.xenproject.org/2018/03/30/join-us-at-root-linux-conference-happening-in-kyiv-ukraine-this-april/
Root Linux Conference is coming to Kyiv, Ukraine on April 14th. The conference is the biggest Linux and embedded conference in Eastern Europe with presenters exploring topics like: Linux in mobile devices, wearables, medical equipment, vehicles, and more. Want to learn about the next generation of embedded solutions? This is the conference for you. Juergen […]
https://blog.xenproject.org/2018/03/30/join-us-at-root-linux-conference-happening-in-kyiv-ukraine-this-april/
Root Linux Conference is coming to Kyiv, Ukraine on April 14th. The conference is the biggest Linux and embedded conference in Eastern Europe with presenters exploring topics like: Linux in mobile devices, wearables, medical equipment, vehicles, and more. Want to learn about the next generation of embedded solutions? This is the conference for you. Juergen […]
Xen Project 4.7.5 and 4.9.2 are available!
https://blog.xenproject.org/2018/04/04/xen-project-4-7-5-and-4-9-2-are-available/
I am pleased to announce the release of Xen 4.7.5 and 4.9.2. Xen Project Maintenance releases are released in line with our Maintenance Release Policy. We recommend that all users of the 4.7 and 4.9 stable series update to the latest point release. These releases are available from their git repositories xenbits.xen.org/gitweb/?p=xen.git;a=shortlog;h=refs/heads/stable-4.7 (tag RELEASE-4.7.5) xenbits.xen.org/gitweb/?p=xen.git;a=shortlog;h=refs/heads/stable-4.9 […]
https://blog.xenproject.org/2018/04/04/xen-project-4-7-5-and-4-9-2-are-available/
I am pleased to announce the release of Xen 4.7.5 and 4.9.2. Xen Project Maintenance releases are released in line with our Maintenance Release Policy. We recommend that all users of the 4.7 and 4.9 stable series update to the latest point release. These releases are available from their git repositories xenbits.xen.org/gitweb/?p=xen.git;a=shortlog;h=refs/heads/stable-4.7 (tag RELEASE-4.7.5) xenbits.xen.org/gitweb/?p=xen.git;a=shortlog;h=refs/heads/stable-4.9 […]
Announcing the Xen Project 4.11 RC and Test Day Schedules
https://blog.xenproject.org/2018/04/18/announcing-the-xen-project-4-11-rc-and-test-day-schedules/
On Tuesday, we created Xen 4.11 RC1 and will release a new release candidate every FRIDAY, until we declare a release candidate as the final candidate and cut the Xen 4.11 release. We will also hold a Test Day every TUESDAY for the release candidate that was released the week prior to the Test Day […]
https://blog.xenproject.org/2018/04/18/announcing-the-xen-project-4-11-rc-and-test-day-schedules/
On Tuesday, we created Xen 4.11 RC1 and will release a new release candidate every FRIDAY, until we declare a release candidate as the final candidate and cut the Xen 4.11 release. We will also hold a Test Day every TUESDAY for the release candidate that was released the week prior to the Test Day […]
Comment on A Brief Introduction to the Xen Project and Virtualization from Mohsen Mostafa Jokar by jazz2125
https://blog.xenproject.org/2017/10/17/a-brief-introduction-to-the-xen-project-and-virtualization-from-mohsen-mostafa-jokar/#comment-496
Thank you for this.
https://blog.xenproject.org/2017/10/17/a-brief-introduction-to-the-xen-project-and-virtualization-from-mohsen-mostafa-jokar/#comment-496
Thank you for this.
XSA-258 and XSA-259 do not affect the security of Qubes OS
https://www.qubes-os.org/news/2018/04/25/xsa-258-259-qubes-not-affected/
The Xen Project has published Xen Security Advisories 258 and 259
(XSA-258 and XSA-259, 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/#258
https://www.qubes-os.org/security/xsa/#259
https://www.qubes-os.org/news/2018/04/25/xsa-258-259-qubes-not-affected/
The Xen Project has published Xen Security Advisories 258 and 259
(XSA-258 and XSA-259, 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/#258
https://www.qubes-os.org/security/xsa/#259
Summer = Xen Project Internships!
https://blog.xenproject.org/2018/04/26/summer-xen-project-internships/
We received a lot of amazing submissions for our summer Outreachy internship program and have accepted Dafna Hirschfeld to join us in creating new execution targets for Unikraft. Unikraft is a Xen Project incubation project that aims to simplify the process of building unikernels through a unified and customizable code base. Currently, Unikraft supports building […]
https://blog.xenproject.org/2018/04/26/summer-xen-project-internships/
We received a lot of amazing submissions for our summer Outreachy internship program and have accepted Dafna Hirschfeld to join us in creating new execution targets for Unikraft. Unikraft is a Xen Project incubation project that aims to simplify the process of building unikernels through a unified and customizable code base. Currently, Unikraft supports building […]
Comment on Summer = Xen Project Internships! by Arhant
https://blog.xenproject.org/2018/04/26/summer-xen-project-internships/#comment-499
I want to contribute in xenproject as a part of my intern projects.As there any open projects in which I can contribute in my summers.
Thanks
Arhant Jain
https://blog.xenproject.org/2018/04/26/summer-xen-project-internships/#comment-499
I want to contribute in xenproject as a part of my intern projects.As there any open projects in which I can contribute in my summers.
Thanks
Arhant Jain
Comment on Summer = Xen Project Internships! by zkeaton
https://blog.xenproject.org/2018/04/26/summer-xen-project-internships/#comment-500
That's great to hear! Please look to applying for next year. Currently the internships are closed for this year.
https://blog.xenproject.org/2018/04/26/summer-xen-project-internships/#comment-500
That's great to hear! Please look to applying for next year. Currently the internships are closed for this year.
Xen Project Announces Schedule for its Annual Developer and Design Summit
https://blog.xenproject.org/2018/05/03/xen-project-announces-schedule-for-its-annual-developer-and-design-summi/
Today, we are excited to announce the program and speakers for the Xen Project Developer and Design Summit. The summit brings together developers, engineers, and Xen Project power users for in-person collaboration and educational presentations. The event will take place in Nanjing Jiangning, China from June 20 -22, 2018. This is the fifth annual Xen […]
https://blog.xenproject.org/2018/05/03/xen-project-announces-schedule-for-its-annual-developer-and-design-summi/
Today, we are excited to announce the program and speakers for the Xen Project Developer and Design Summit. The summit brings together developers, engineers, and Xen Project power users for in-person collaboration and educational presentations. The event will take place in Nanjing Jiangning, China from June 20 -22, 2018. This is the fifth annual Xen […]
QSB #39: Xen vulnerability (XSA-260) and GUI daemon issue
https://www.qubes-os.org/news/2018/05/08/qsb-39/
Dear Qubes Community,
We have just published Qubes Security Bulletin (QSB) #39:
Xen vulnerability (XSA-260) and GUI daemon issue.
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 #39 in the qubes-secpack:
https://github.com/QubesOS/qubes-secpack/blob/master/QSBs/qsb-039-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/
---===[ Qubes Security Bulletin #39 ]===---
May 8, 2018
Xen vulnerability (XSA-260) and GUI daemon issue
Summary
========
Today, the Xen Security Team released Xen Security Advisories 260
through 262. Among these, only XSA-260 affects the security of Qubes
OS. The bug described in XSA-260 allows an attacker controlling a PV
domain to break out to dom0. This is a critical bug for Qubes 3.2, but
for Qubes 4.0 is much less severe, since all the domains that run
untrusted code in Qubes 4.0 are either PVH or HVM by default.
Additionally, Christoffer Kugg Jerkeby discovered a situation in which
Qubes GUI virtualization could allow a VM to produce a window with
borders that are white instead of the color of the VM's label. (In
Qubes, border colors are used as front-line indicators of trust.)
However, a VM cannot use this vulnerability to draw borders with a
non-white color other than the correct one. A very similar bug was
fixed as part of QSB #34 [1], but the fix missed this one case, as
described below.
Technical details
==================
Xen issues
-----------
Xen Security Advisory 260 [2]:
| When switching stacks, it is critical to have a matching stack segment
| and stack pointer. To allow an atomic update from what would otherwise
| be two adjacent instructions, an update which changes the stack segment
| (either a mov or pop instruction with %ss encoded as the destination
| register) sets the movss shadow for one instruction.
|
| The exact behaviour of the movss shadow is poorly understood.
|
| In practice, a movss shadow delays some debug exceptions (e.g. from a
| hardware breakpoint) until the subsequent instruction has completed. If
| the subsequent instruction normally transitions to supervisor mode
| (e.g. a system call), then the debug exception will be taken after the
| transition to ring0 is completed.
|
| For most transitions to supervisor mode, this only confuses Xen into
| printing a lot of debugging information. For the syscall instruction
| however, the exception gets taken before the syscall handler can move
| off the guest stack.
|
| A malicious PV guest can escalate their privilege to that of the
| hypervisor.
GUI daemon issue
----------------
In QSB #34, we reported a similar bug involving the Qubes GUI daemon.
Whenever a VM displays a borderless window in Qubes, the GUI daemon is
responsible for drawing a colored border around it. In particular,
whenever a window content update is sent for the border area of a
borderless window, the GUI daemon is supposed to draw a 2px border in
that location.
The bug reported in QSB #34 occurred when a VM showed a borderless
splash screen window with a custom shape. While custom window shapes are
not supported in Qubes OS, VMs do not know this. The VM still thought
the custom-shaped window was there, so it never sent window content
updates outside of the custom shape. Hence, it never sent window content
updates for the border areas of custom-shaped windows. Since there were
no window content updates for the border areas, the GUI daemon failed to
recognize that it should draw colored borders in those locations. As a
result, custom-shaped splash screen windows had no borders at all. From
https://www.qubes-os.org/news/2018/05/08/qsb-39/
Dear Qubes Community,
We have just published Qubes Security Bulletin (QSB) #39:
Xen vulnerability (XSA-260) and GUI daemon issue.
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 #39 in the qubes-secpack:
https://github.com/QubesOS/qubes-secpack/blob/master/QSBs/qsb-039-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/
---===[ Qubes Security Bulletin #39 ]===---
May 8, 2018
Xen vulnerability (XSA-260) and GUI daemon issue
Summary
========
Today, the Xen Security Team released Xen Security Advisories 260
through 262. Among these, only XSA-260 affects the security of Qubes
OS. The bug described in XSA-260 allows an attacker controlling a PV
domain to break out to dom0. This is a critical bug for Qubes 3.2, but
for Qubes 4.0 is much less severe, since all the domains that run
untrusted code in Qubes 4.0 are either PVH or HVM by default.
Additionally, Christoffer Kugg Jerkeby discovered a situation in which
Qubes GUI virtualization could allow a VM to produce a window with
borders that are white instead of the color of the VM's label. (In
Qubes, border colors are used as front-line indicators of trust.)
However, a VM cannot use this vulnerability to draw borders with a
non-white color other than the correct one. A very similar bug was
fixed as part of QSB #34 [1], but the fix missed this one case, as
described below.
Technical details
==================
Xen issues
-----------
Xen Security Advisory 260 [2]:
| When switching stacks, it is critical to have a matching stack segment
| and stack pointer. To allow an atomic update from what would otherwise
| be two adjacent instructions, an update which changes the stack segment
| (either a mov or pop instruction with %ss encoded as the destination
| register) sets the movss shadow for one instruction.
|
| The exact behaviour of the movss shadow is poorly understood.
|
| In practice, a movss shadow delays some debug exceptions (e.g. from a
| hardware breakpoint) until the subsequent instruction has completed. If
| the subsequent instruction normally transitions to supervisor mode
| (e.g. a system call), then the debug exception will be taken after the
| transition to ring0 is completed.
|
| For most transitions to supervisor mode, this only confuses Xen into
| printing a lot of debugging information. For the syscall instruction
| however, the exception gets taken before the syscall handler can move
| off the guest stack.
|
| A malicious PV guest can escalate their privilege to that of the
| hypervisor.
GUI daemon issue
----------------
In QSB #34, we reported a similar bug involving the Qubes GUI daemon.
Whenever a VM displays a borderless window in Qubes, the GUI daemon is
responsible for drawing a colored border around it. In particular,
whenever a window content update is sent for the border area of a
borderless window, the GUI daemon is supposed to draw a 2px border in
that location.
The bug reported in QSB #34 occurred when a VM showed a borderless
splash screen window with a custom shape. While custom window shapes are
not supported in Qubes OS, VMs do not know this. The VM still thought
the custom-shaped window was there, so it never sent window content
updates outside of the custom shape. Hence, it never sent window content
updates for the border areas of custom-shaped windows. Since there were
no window content updates for the border areas, the GUI daemon failed to
recognize that it should draw colored borders in those locations. As a
result, custom-shaped splash screen windows had no borders at all. From
the GUI daemon's perspective, all VMs are untrusted insofar as they
cannot be relied upon to cooperate in drawing the correct colored
borders around their windows. Therefore, the blame for this bug lies
solely with the GUI daemon, not with the VM that failed to send window
content updates.
While the patch for QSB #34 fixed the case just described, it failed to
fix the case in which no window image is sent at all before mapping the
window. In this latter case, the argument sanitization section of the
do_shm_update function is skipped, resulting in arguments being ignored.
This, in turn, results in the entire window, including its borders,
appearing as a solid white rectangle on the screen.
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-40
- qubes-gui-dom0, version 3.2.13
For Qubes 4.0:
- Xen packages, version 4.8.2-7
- qubes-gui-dom0, version 4.0.8
The packages are to be installed in dom0 via the Qubes VM Manager or via
the qubes-dom0-update command as follows:
For updates from the stable repository (not immediately available):
$ sudo qubes-dom0-update
For updates from the security-testing repository:
$ sudo qubes-dom0-update --enablerepo=qubes-dom0-security-testing
A system restart will be required afterwards.
These packages will migrate from the security-testing repository to the
current (stable) repository over the next two weeks after being tested
by the community.
If you use Anti Evil Maid, you will need to reseal your secret
passphrase to new PCR values, as PCR18+19 will change due to the new
Xen binaries.
Credits
========
The GUI issue was discovered by Christoffer Kugg Jerkeby.
For other issues, see the original Xen Security Advisories.
References
===========
[1] https://www.qubes-os.org/news/2017/10/12/qsb-34/
[2] https://xenbits.xen.org/xsa/advisory-260.html
--
The Qubes Security Team
https://www.qubes-os.org/security/
cannot be relied upon to cooperate in drawing the correct colored
borders around their windows. Therefore, the blame for this bug lies
solely with the GUI daemon, not with the VM that failed to send window
content updates.
While the patch for QSB #34 fixed the case just described, it failed to
fix the case in which no window image is sent at all before mapping the
window. In this latter case, the argument sanitization section of the
do_shm_update function is skipped, resulting in arguments being ignored.
This, in turn, results in the entire window, including its borders,
appearing as a solid white rectangle on the screen.
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-40
- qubes-gui-dom0, version 3.2.13
For Qubes 4.0:
- Xen packages, version 4.8.2-7
- qubes-gui-dom0, version 4.0.8
The packages are to be installed in dom0 via the Qubes VM Manager or via
the qubes-dom0-update command as follows:
For updates from the stable repository (not immediately available):
$ sudo qubes-dom0-update
For updates from the security-testing repository:
$ sudo qubes-dom0-update --enablerepo=qubes-dom0-security-testing
A system restart will be required afterwards.
These packages will migrate from the security-testing repository to the
current (stable) repository over the next two weeks after being tested
by the community.
If you use Anti Evil Maid, you will need to reseal your secret
passphrase to new PCR values, as PCR18+19 will change due to the new
Xen binaries.
Credits
========
The GUI issue was discovered by Christoffer Kugg Jerkeby.
For other issues, see the original Xen Security Advisories.
References
===========
[1] https://www.qubes-os.org/news/2017/10/12/qsb-34/
[2] https://xenbits.xen.org/xsa/advisory-260.html
--
The Qubes Security Team
https://www.qubes-os.org/security/
Fedora 26 and Debian 8 approaching EOL
https://www.qubes-os.org/news/2018/05/23/fedora-26-and-debian-8-approaching-eol/
Fedora 26 will reach EOL (end-of-life (https://fedoraproject.org/wiki/Fedora_Release_Life_Cycle#Maintenance_Schedule)) on 2018-06-01, and Debian 8
(“Jessie” full, not LTS (https://wiki.debian.org/DebianReleases)) will reach EOL on
2018-06-06. We strongly recommend that all Qubes users upgrade their
Fedora 26 and Debian 8 TemplateVMs and StandaloneVMs to Fedora 27 and
Debian 9 or higher, respectively, by these EOL dates. We provide
step-by-step upgrade instructions for upgrading from Fedora 26 to 27 (https://www.qubes-os.org/doc/template/fedora/upgrade-26-to-27/),
Fedora 27 to 28 (https://www.qubes-os.org/doc/template/fedora/upgrade-27-to-28/), and Debian 8 to 9 (https://www.qubes-os.org/doc/template/debian/upgrade-8-to-9/). 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 fresh Fedora 27, Fedora 28, and Debian 9 TemplateVM
packages through the official Qubes repositories, which you can install
in dom0 by following the standard installation instructions for Fedora (https://www.qubes-os.org/doc/templates/fedora/#installing)
and Debian (https://www.qubes-os.org/doc/templates/debian/#installing) TemplateVMs.
After upgrading your TemplateVMs, please remember to set all qubes that
were using the old template to use the new one. The instructions to do
this can be found in the upgrade instructions for Fedora 26 to 27 (https://www.qubes-os.org/doc/template/fedora/upgrade-26-to-27/),
Fedora 27 to 28 (https://www.qubes-os.org/doc/template/fedora/upgrade-27-to-28/), and Debian 8 to 9 (https://www.qubes-os.org/doc/template/debian/upgrade-8-to-9/).
Please note that no user action is required regarding the OS version in
dom0. If you’re using Qubes 3.2 or 4.0, there is no dom0 OS upgrade
available, since none is currently required. For details, please see our
Note on dom0 and EOL (https://www.qubes-os.org/doc/supported-versions/#note-on-dom0-and-eol).
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/05/23/fedora-26-and-debian-8-approaching-eol/
Fedora 26 will reach EOL (end-of-life (https://fedoraproject.org/wiki/Fedora_Release_Life_Cycle#Maintenance_Schedule)) on 2018-06-01, and Debian 8
(“Jessie” full, not LTS (https://wiki.debian.org/DebianReleases)) will reach EOL on
2018-06-06. We strongly recommend that all Qubes users upgrade their
Fedora 26 and Debian 8 TemplateVMs and StandaloneVMs to Fedora 27 and
Debian 9 or higher, respectively, by these EOL dates. We provide
step-by-step upgrade instructions for upgrading from Fedora 26 to 27 (https://www.qubes-os.org/doc/template/fedora/upgrade-26-to-27/),
Fedora 27 to 28 (https://www.qubes-os.org/doc/template/fedora/upgrade-27-to-28/), and Debian 8 to 9 (https://www.qubes-os.org/doc/template/debian/upgrade-8-to-9/). 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 fresh Fedora 27, Fedora 28, and Debian 9 TemplateVM
packages through the official Qubes repositories, which you can install
in dom0 by following the standard installation instructions for Fedora (https://www.qubes-os.org/doc/templates/fedora/#installing)
and Debian (https://www.qubes-os.org/doc/templates/debian/#installing) TemplateVMs.
After upgrading your TemplateVMs, please remember to set all qubes that
were using the old template to use the new one. The instructions to do
this can be found in the upgrade instructions for Fedora 26 to 27 (https://www.qubes-os.org/doc/template/fedora/upgrade-26-to-27/),
Fedora 27 to 28 (https://www.qubes-os.org/doc/template/fedora/upgrade-27-to-28/), and Debian 8 to 9 (https://www.qubes-os.org/doc/template/debian/upgrade-8-to-9/).
Please note that no user action is required regarding the OS version in
dom0. If you’re using Qubes 3.2 or 4.0, there is no dom0 OS upgrade
available, since none is currently required. For details, please see our
Note on dom0 and EOL (https://www.qubes-os.org/doc/supported-versions/#note-on-dom0-and-eol).
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.
Partnering with the Freedom of the Press Foundation
https://www.qubes-os.org/news/2018/05/24/partnering-with-the-freedom-of-the-press-foundation/
We’re pleased to announce that the Freedom of the Press Foundation
(FPF) (https://freedom.press/) has become a Qubes Partner (https://www.qubes-os.org/partners/#freedom-of-the-press-foundation). We look forward to continuing to
work with the FPF on an integrated SecureDrop Workstation (https://github.com/freedomofpress/securedrop-workstation) based on
Qubes OS. For more about what this collaboration entails and our next
steps together, please see today’s announcement on the SecureDrop
blog (https://securedrop.org/news/road-towards-integrated-securedrop-workstation/).
https://www.qubes-os.org/news/2018/05/24/partnering-with-the-freedom-of-the-press-foundation/
We’re pleased to announce that the Freedom of the Press Foundation
(FPF) (https://freedom.press/) has become a Qubes Partner (https://www.qubes-os.org/partners/#freedom-of-the-press-foundation). We look forward to continuing to
work with the FPF on an integrated SecureDrop Workstation (https://github.com/freedomofpress/securedrop-workstation) based on
Qubes OS. For more about what this collaboration entails and our next
steps together, please see today’s announcement on the SecureDrop
blog (https://securedrop.org/news/road-towards-integrated-securedrop-workstation/).
QSB #40: Information leaks due to processor speculative store bypass (XSA-263)
https://www.qubes-os.org/news/2018/05/24/qsb-40/
Dear Qubes Community,
We have just published Qubes Security Bulletin (QSB) #40: Information
leaks due to processor speculative store bypass (XSA-263). 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 #40 in the qubes-secpack:
https://github.com/QubesOS/qubes-secpack/blob/master/QSBs/qsb-040-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-263 in the XSA Tracker:
https://www.qubes-os.org/security/xsa/#263
---===[ Qubes Security Bulletin #40 ]===---
2018-05-24
Information leaks due to processor speculative store bypass (XSA-263)
Summary
========
On 2018-05-21, the Xen Security Team published Xen Security Advisory
263 (CVE-2018-3639 / XSA-263) [1] with the following denoscription:
| Contemporary high performance processors may use a technique commonly
| known as Memory Disambiguation, whereby speculative execution may
| proceed past unresolved stores. This opens a speculative sidechannel
| in which loads from an address which have had a recent store can
| observe and operate on the older, stale, value.
Please note that this issue was neither predisclosed nor embargoed.
Consequently, the Qubes Security Team has not had time to analyze it in
advance of issuing this bulletin.
Impact
=======
According to XSA-263, the impact of this issue is as follows:
| An attacker who can locate or create a suitable code gadget in a
| different privilege context may be able to infer the content of
| arbitrary memory accessible to that other privilege context.
|
| At the time of writing, there are no known vulnerable gadgets in the
| compiled hypervisor code. Xen has no interfaces which allow JIT code
| to be provided. Therefore we believe that the hypervisor itself is
| not vulnerable. Additionally, we do not think there is a viable
| information leak by one Xen guest against another non-cooperating
| guest.
|
| However, in most configurations, within-guest information leak is
| possible. Mitigation for this generally depends on guest changes
| (for which you must consult your OS vendor) *and* on hypervisor
| support, provided in this advisory.
In light of this, XSA-263 appears to be less severe than the related
Spectre and Meltdown vulnerabilities we discussed in QSB #37 [2].
Patching
=========
The specific packages that resolve the problems discussed in this
bulletin are as follows:
For Qubes 3.2:
- Xen packages, version 4.6.6-41
For Qubes 4.0:
- Xen packages, version 4.8.3-8
The packages are to be installed in dom0 via the Qubes VM Manager or via
the qubes-dom0-update command as follows:
For updates from the stable repository (not immediately available):
$ sudo qubes-dom0-update
For updates from the security-testing repository:
$ sudo qubes-dom0-update --enablerepo=qubes-dom0-security-testing
A system restart will be required afterwards.
These packages will migrate from the security-testing repository to the
current (stable) repository over the next two weeks after being tested
by the community.
If you use Anti Evil Maid, you will need to reseal your secret
passphrase to new PCR values, as PCR18+19 will change due to the new
Xen binaries.
In addition, Intel Corporation has announced that microcode updates
will be available soon [3]:
| Variant 3a is mitigated in the same processor microcode updates as
| Variant 4, and Intel has released these updates in beta form to OEM
| system manufacturers and system software vendors. They are being
| readied for production release, and will be delivered to consumers
| and IT Professionals in the coming weeks.
https://www.qubes-os.org/news/2018/05/24/qsb-40/
Dear Qubes Community,
We have just published Qubes Security Bulletin (QSB) #40: Information
leaks due to processor speculative store bypass (XSA-263). 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 #40 in the qubes-secpack:
https://github.com/QubesOS/qubes-secpack/blob/master/QSBs/qsb-040-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-263 in the XSA Tracker:
https://www.qubes-os.org/security/xsa/#263
---===[ Qubes Security Bulletin #40 ]===---
2018-05-24
Information leaks due to processor speculative store bypass (XSA-263)
Summary
========
On 2018-05-21, the Xen Security Team published Xen Security Advisory
263 (CVE-2018-3639 / XSA-263) [1] with the following denoscription:
| Contemporary high performance processors may use a technique commonly
| known as Memory Disambiguation, whereby speculative execution may
| proceed past unresolved stores. This opens a speculative sidechannel
| in which loads from an address which have had a recent store can
| observe and operate on the older, stale, value.
Please note that this issue was neither predisclosed nor embargoed.
Consequently, the Qubes Security Team has not had time to analyze it in
advance of issuing this bulletin.
Impact
=======
According to XSA-263, the impact of this issue is as follows:
| An attacker who can locate or create a suitable code gadget in a
| different privilege context may be able to infer the content of
| arbitrary memory accessible to that other privilege context.
|
| At the time of writing, there are no known vulnerable gadgets in the
| compiled hypervisor code. Xen has no interfaces which allow JIT code
| to be provided. Therefore we believe that the hypervisor itself is
| not vulnerable. Additionally, we do not think there is a viable
| information leak by one Xen guest against another non-cooperating
| guest.
|
| However, in most configurations, within-guest information leak is
| possible. Mitigation for this generally depends on guest changes
| (for which you must consult your OS vendor) *and* on hypervisor
| support, provided in this advisory.
In light of this, XSA-263 appears to be less severe than the related
Spectre and Meltdown vulnerabilities we discussed in QSB #37 [2].
Patching
=========
The specific packages that resolve the problems discussed in this
bulletin are as follows:
For Qubes 3.2:
- Xen packages, version 4.6.6-41
For Qubes 4.0:
- Xen packages, version 4.8.3-8
The packages are to be installed in dom0 via the Qubes VM Manager or via
the qubes-dom0-update command as follows:
For updates from the stable repository (not immediately available):
$ sudo qubes-dom0-update
For updates from the security-testing repository:
$ sudo qubes-dom0-update --enablerepo=qubes-dom0-security-testing
A system restart will be required afterwards.
These packages will migrate from the security-testing repository to the
current (stable) repository over the next two weeks after being tested
by the community.
If you use Anti Evil Maid, you will need to reseal your secret
passphrase to new PCR values, as PCR18+19 will change due to the new
Xen binaries.
In addition, Intel Corporation has announced that microcode updates
will be available soon [3]:
| Variant 3a is mitigated in the same processor microcode updates as
| Variant 4, and Intel has released these updates in beta form to OEM
| system manufacturers and system software vendors. They are being
| readied for production release, and will be delivered to consumers
| and IT Professionals in the coming weeks.