Qubes Canary #17
https://www.qubes-os.org/news/2018/10/15/canary-17/

Dear Qubes Community,

We have published Qubes Canary #17. 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 #17 in the qubes-secpack:

https://github.com/QubesOS/qubes-secpack/blob/master/canaries/canary-017-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 #17 ]===---


Statements
-----------

The Qubes core developers who have digitally signed this file [1]
state the following:

1. The date of issue of this canary is October 15, 2018.

2. There have been 43 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 January 2019. 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
Mon, 15 Oct 2018 12:56:41 +0000

$ feedstail -1 -n5 -f '{noscript}' -u https://www.spiegel.de/international/index.rss
Merkel's Bavaria Headache: Berlin Coalition Emerges Even Weaker
A European IMF: The New Face of the Eurozone Bailout Fund
Social Design Award: Vote For Your Favorite Neighborhood Project
Rape Allegations: Ronaldo's Defense Team Develops a Strategy
Operation Mekong: China Solidifies Its Influence in Southeast Asia

$ feedstail -1 -n5 -f '{noscript}' -u https://rss.nytimes.com/services/xml/rss/nyt/World.xml
‘Our Hands Can Reach You’: Khashoggi Case Shakes Saudi Dissidents Abroad
Brazil Edges Toward Bolsonaro as a ‘Last Resort’ Leader
How to Attract a Killer Tigress? Try a Man’s Cologne
Kim Jong-un Invites Pope Francis to North Korea
Bulgarian Journalist, Host of Anticorruption TV Show, Is Raped and Killed

$ feedstail -1 -n5 -f '{noscript}' -u https://feeds.bbci.co.uk/news/world/rss.xml
Jamal Khashoggi: Turkey to search Saudi consulate in Istanbul
France weather: Red alert as flash floods kill 13 in south-west
Buckethead the bear cub's head freed from jar after three days
Hostage held at Cologne main train station
China star detained for 'anthem insult'

$ feedstail -1 -n5 -f '{noscript}' -u http://feeds.reuters.com/reuters/worldnews
Jordan and Syria reopen Nassib border crossing

U.S. still aiming to cut Iran oil sales to zero, market well-supplied: U.S. envoy for Iran
Saudi king orders probe in Khashoggi case, Turkey to search consulate
Bavaria election shakes Merkel's coalition, far-right rejoices
Merkel vows to regain trust after conservative losses in Bavaria


$ python3 -c 'import sys, json; print(json.load(sys.stdin)['\''blocks'\''][10]['\''hash'\''])'
$ curl -s 'https://blockchain.info/blocks/?format=json'
000000000000000000201919eaab0aa9d10b9f1458d84f60434533d7cb915192

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!

Celebrating 15 Years of the Xen Project and Our Future
https://blog.xenproject.org/2018/10/23/celebrating-15-years-of-the-xen-project-and-our-future/

In the 1990s, Xen was a part of a research project to build a public computing infrastructure on the Internet led by Ian Pratt and Keir Fraser at The University of Cambridge Computer Laboratory. The Xen Project is now one of the most popular open source hypervisors and amasses more than 10 million users, and […]

XSA-278 does not affect the security of Qubes OS
https://www.qubes-os.org/news/2018/10/24/xsa-278-qubes-not-affected/

Dear Qubes Community,

The Xen Project has published Xen Security Advisory 278 (XSA-278). 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/#278

Thank you, Joanna!
https://www.qubes-os.org/news/2018/10/25/thank-you-joanna/

The Qubes OS project was founded by Joanna Rutkowska in 2009 (https://blog.invisiblethings.org/2010/04/07/introducing-qubes-os.html).
I joined the project in its early days, before Qubes 1.0, and have been part of
the team under Joanna’s leadership since then. Over the past nine years, the
system architecture has been enhanced multiple times, including major changes
like HVM with stubdomain support (https://blog.invisiblethings.org/2012/12/14/qubes-2-beta-1-with-initial-windows.html), the Hypervisor Abstraction Layer
(HAL) (https://blog.invisiblethings.org/2013/03/21/introducing-qubes-odyssey-framework.html), and finally, in Qubes 4.0, the Admin API (https://blog.invisiblethings.org/2017/06/27/qubes-admin-api.html) and switch
to PVH (https://www.qubes-os.org/news/2016/09/02/4-0-minimum-requirements-3-2-extended-support/) as the main VM type. The project has also matured a lot. We
started as a set of a few (https://github.com/QubesOS/qubes-doc/blob/6ac51fb134093168ec3900c9bed22c3a86bcd021/SourceCode.md) manually built (https://groups.google.com/d/msg/qubes-devel/cQ9yVxPMfoo/CTIXml3B_NcJ) packages
installed on top of Fedora 12 (https://github.com/QubesOS/qubes-doc/blob/d6639edf47a7b85e54cd470380de25e1b7403407/InstallationGuide.md). Now, we have a build
infrastructure (https://github.com/QubesOS/qubes-infrastructure/blob/master/README.md#detailed-denoscription-of-the-infrastructure), documented versioning scheme (https://www.qubes-os.org/doc/version-scheme/)
and release schedules (https://www.qubes-os.org/doc/releases/schedules/), coding guidelines (https://www.qubes-os.org/doc/coding-style/),
and automated tests (https://www.qubes-os.org/doc/automated-tests/). The core part of Qubes has also been
rewritten a few times since its original release. The project’s success can be
measured by its growing community, including deployments like SecureDrop (https://securedrop.org/news/road-towards-integrated-securedrop-workstation/) and
Let’s Encrypt (https://twitter.com/RMLLsec16/status/749982515948027904).

Today Joanna announced (https://www.qubes-os.org/news/2018/10/25/the-next-chapter/) that she is stepping down from the
project’s leadership role and nominating me as her successor. I have been the
project’s lead engineer for a few years now, and I’m honored to officially lead
the project as a whole. I plan to continue the direction in which Qubes OS has
been going, providing defenses well ahead (https://twitter.com/rootkovska/status/530416582426902528) of new attacks.

On behalf of the whole Qubes team, I’d like to thank Joanna for all of her
years of work on the project. Under her leadership, Qubes OS has accomplished a
lot, with only some of its many successes mentioned above. We look forward to
continuing to benefit from her expertise as an advisor. At the same time, we
wish her all the best in her new role on the Golem Project!

The Next Chapter: From the Endpoint to the Cloud
https://www.qubes-os.org/news/2018/10/25/the-next-chapter/

Earlier this year, I decided to take a sabbatical. I wanted to reflect on my
infosec work and decide what I would like to focus on in the coming years. As
you probably know, I’ve spent the last nine years mostly fighting the battle to
secure the endpoint, more specifically creating, developing, architecting, and
promoting Qubes OS (https://www.qubes-os.org/), as well as the more general
concept of “Security through
Distrusting” (https://www.blackhat.com/eu-17/briefings.html#security-through-distrusting).

Over these past nine years, Qubes OS has grown from a research-inspired
proof-of-concept into a reasonably mature, large open-source project with
dozens of contributors (https://www.qubes-os.org/team/) and tens of thousands
of users (https://www.qubes-os.org/statistics/), including some high-profile
security experts (https://www.qubes-os.org/experts/).

There are still many challenges ahead for Qubes, however. The primary two are
improving hardware compatibility and UX. I think addressing these challenges
will mostly be an iterative process of gradual improvement, but it will
nonetheless require a lot of time and resources.

Another challenge is the trustworthiness of the x86
platform (https://blog.invisiblethings.org/papers/2015/x86_harmful.pdf). Again,
I remain optimistic that many things could be improved on this front, as well
(see, for example, my proposal for a stateless laptop
design (https://blog.invisiblethings.org/papers/2015/state_harmful.pdf)).
Admittedly, such work will require significantly more resources, but I know
there is a lot of interest in this area, and it just needs proper coordination
to happen.

Despite all of these interesting challenges (especially with platform
trustworthiness), I’ve decided I’d like to switch my focus to something other
than endpoint security. While I still believe that the security of our digital
lives starts and ends with the trustworthiness of the client devices we use
(which today include much more than just laptops and desktops, of course), I
also recognize that the state of endpoint device security has significantly
improved over the past decade. At the same time, most of our data and activities
have migrated from local devices to the cloud.

And yet, there are fundamental problems with cloud
trustworthiness (https://twitter.com/rootkovska/status/1051392157096001536), or
the lack thereof. These problems could be summarized as the need for users (i.e.
all of us) to be forced to trust three different entities: (1) the service
providers who own our data (e.g. the vendor of your fitness tracking app), (2)
the hosting infrastructure owners, who can both access our data as well as deny
us use of the service at their discretion (e.g. AWS, Azure, GCP), and (3) the
networking infrastructure operators, who can also selectively cut us off from
the services (e.g. to implement some form of censorship).

These are very important problems, in my opinion, and I’d like to work now on
making the cloud more trustworthy, specifically by limiting the amount of trust
we have to place in it.

So, this month I’ve joined the Golem Project (https://golem.network/) as a
Chief Strategy Officer, also doubling as Chief Security Officer (conveniently,
both roles have the same CSO acronym :) The double nature of my role emphasizes
the close relationships among the long-term roadmap, technical architecture,
as well as product- and operations-security in Golem.

Why Golem? Because Golem is a very unique project. Golem has been on a mission
to build a “decentralized computer” out of a heterogeneous network of
third-party provided computers. Founded two years ago through a very successful
crowdfunding campaign, it instantly gained an impressive amount of funding,
which allowed it to build a strong development team (incidentally, mostly based
in my favorite city – Warsaw).

The distributed funding model has also essentially eliminated two common
obstacles most tech startups face: lack of money to hire enough people and the
need to implement investors’ (rather than the founders’) agenda. In this
respect Golem seems to be as independent as one could realistically imagine.

Most importantly, we (ITL), have already been
working (https://blog.invisiblethings.org/2018/06/11/graphene-ng.html) with
Golem over the past year. During that time I’ve had enough time to get to know
some of the key people in the project, understand their personal agendas, and
conclude they might be very much inline with my own.

As for the future of Qubes, I don’t think much will change here. In recent
years, Marek
Marczykowski-Górecki (https://www.qubes-os.org/team/#marek-marczykowski-g%C3%B3recki)
has been effectively leading most of the day-to-day efforts with Qubes OS
development, while I’ve focused mostly on long-term architecture planning and
various research activities, such as our SGX-related work. Marek will continue
to lead Qubes now, so I’m reassured about the future of the project. I will also
remain as an advisor to the Qubes OS Project, as well as… its user, though I’ve
recently also been embracing other systems, including – of course – the cloud.

Finally, I’d like to thank my (present and past) ITL colleagues. We have
undertaken quite a few projects together, of which Qubes OS is probably the most
challenging and spectacular. Yet it was hardly the only one. There was also all
the (allegedly
pioneering (https://twitter.com/dwizzzleMSFT/status/1006733071511519232))
offensive system security research done together with Rafał Wojtczuk and Alex
Tereshkin. This research was instrumental in our subsequent work on Qubes OS,
and I think it will again prove useful for my work on Golem.

Qubes OS 4.0.1-rc1 has been released!
https://www.qubes-os.org/news/2018/11/05/qubes-401-rc1/

We’re pleased to announce the first release candidate for Qubes 4.0.1!
This is the first of at least two planned point releases for version 4.0.
Features:

All 4.0 dom0 updates to date
Fedora 29 TemplateVM
Debian 9 TemplateVM
Whonix 14 Gateway and Workstation TemplateVMs
Linux kernel 4.14
Qubes 4.0.1-rc1 is available on the Downloads (https://www.qubes-os.org/downloads/#qubes-release-4-0-1-rc1) page.

What is a point release?

A point release does not designate a separate, new version of Qubes OS.
Rather, it designates its respective major or minor release (in this
case, 4.0) inclusive of all updates up to a certain point. Installing
Qubes 4.0 and fully updating it results in the same system as installing
Qubes 4.0.1.

What should I do?

If you’re currently using an up-to-date Qubes 4.0 installation, then
your system is already equivalent to a Qubes 4.0.1 installation. No
action is needed.

Regardless of your current OS, if you wish to install (or reinstall)
Qubes 4.0 for any reason, then the 4.0.1 ISO will make this more
convenient and secure, since it bundles all Qubes 4.0 updates to date.
It will be especially helpful for users whose hardware is too new to be
compatible with the original Qubes 4.0 installer.

Release candidate planning

We expect that there will be a second release candidate (4.0.1-rc2) following
this one (4.0.1-rc1). The second release candidate will include a fix for the
Nautilus bug reported in #4460 (https://github.com/QubesOS/qubes-issues/issues/4460) along with any other available fixes for bugs
reported against this release candidate. As usual, you can help by reporting
any bugs you encounter (https://www.qubes-os.org/doc/reporting-bugs/).

What about Qubes 3.2.1?

We announced the release of 3.2.1-rc1 one month ago (https://www.qubes-os.org/news/2018/10/05/qubes-321-rc1/). Since no serious
problems have been discovered in 3.2.1-rc1, we plan to build the final version
of Qubes 3.2.1 at the end of this week.

Qubes Security Team Update
https://www.qubes-os.org/news/2018/11/05/qubes-security-team-update/

As we recently announced, Joanna Rutkowska (https://www.qubes-os.org/team/#joanna-rutkowska) has turned over leadership of the
Qubes OS Project to Marek Marczykowski-Górecki (https://www.qubes-os.org/team/#marek-marczykowski-g%C3%B3recki) (see Joanna’s announcement (https://www.qubes-os.org/news/2018/10/25/the-next-chapter/)
and Marek’s announcement (https://www.qubes-os.org/news/2018/10/25/thank-you-joanna/)). In this post, we’ll discuss the implications of
these changes for the Qubes Security Team and how we’re addressing them.

What is the Qubes Security Team?

The Qubes Security Team (QST) (https://www.qubes-os.org/security/#the-qubes-security-team) is the subset of the Qubes Team (https://www.qubes-os.org/team/) that is
responsible for ensuring the security of Qubes OS and the Qubes OS Project.
In particular, the QST is responsible for:

Responding to reported security issues (https://www.qubes-os.org/security/#reporting-security-issues-in-qubes-os)
Evaluating whether Xen Security Advisories (XSAs) (https://www.qubes-os.org/security/xsa/) affect the security of
Qubes OS
Writing, applying, and/or distributing security patches to fix
vulnerabilities in Qubes OS
Writing, signing, and publishing Qubes Security Bulletins (QSBs) (https://www.qubes-os.org/security/bulletins/)
Writing, signing, and publishing Qubes Canaries (https://www.qubes-os.org/security/canaries/)
Generating, safeguarding, and using the project’s PGP keys (https://keys.qubes-os.org/keys/)
As a security-oriented operating system, the QST is fundamentally important to
Qubes, and every Qubes user implicitly trusts the members of the QST by virtue
of the actions listed above.

How does the recent change in leadership affect the QST?

Until now, the two members of the QST have been Joanna and Marek. With Joanna’s
new role at the Golem Project, she will no longer have time to function as a QST
member. Therefore, Joanna will officially transfer ownership of the Qubes
Master Signing Key (QMSK) (https://www.qubes-os.org/security/verifying-signatures/#1-get-the-qubes-master-signing-key-and-verify-its-authenticity) to Marek, and she will no longer sign QSBs.

However, due to the nature of PGP keys, there is no way to guarantee that Joanna
will not retain a copy of the QMSK after transferring ownership to Marek. Since
anyone in possession of the QMSK is a potential attack vector against the
project, Joanna will continue to sign Qubes Canaries (https://www.qubes-os.org/security/canaries/) in perpetuity.

With Joanna’s departure from the QST, Marek would remain as its sole member.
Given the critical importance of the QST to the project, however, we believe
that a single member would be insufficient. Therefore, after careful
consideration, we have selected a new member for the QST from among our
experienced Qubes Team members: Simon Gaiser (aka HW42) (https://www.qubes-os.org/team/#simon-gaiser-aka-hw42).

About Simon

Simon (https://www.qubes-os.org/team/#simon-gaiser-aka-hw42) has been a member of the Qubes Team for over two years and has been a
contributor to the project since 2014. He has worked on many different parts of
the Qubes codebase, including core, Xen, kernel, and GUI components. Earlier
this year, he joined Invisible Things Lab (ITL) and has been gaining experience
with other security projects. His thorough knowledge of Qubes OS, ability to
assess the severity of security vulnerabilities, and experience preparing Xen
patches make him very well-suited to the QST. Most importantly, both Joanna and
Marek trust him with the responsibilities of this important role. We are pleased
to announce Simon’s new role as a QST member. Congratulations, Simon, and thank
you for working to keep Qubes secure!

Comment on Celebrating 15 Years of the Xen Project and Our Future by fbifido
https://blog.xenproject.org/2018/10/23/celebrating-15-years-of-the-xen-project-and-our-future/#comment-561

Hi,
To me, it does not seem like Xen is doing all that it can to get more people using it.
you seem to try and not compete with hyper-v or VMware, but openly tell customers that they can move from VMware to XenServer, but not from hyper-v to XenServer.
needed feature:
-built-in VM network micro-segmentation must be part of the core of Xen.
-- you can use simple access list or network list AWS but per VM.
-built-in security guard must be part of the core of Xen.

(Xen does not need add-ons for these features, they need to bake into the core of XEN)

thanks.

Comment on Celebrating 15 Years of the Xen Project and Our Future by fbifido
https://blog.xenproject.org/2018/10/23/celebrating-15-years-of-the-xen-project-and-our-future/#comment-562

correction:
"— you can use simple access list or network list, like AWS, but per VM"

Comment on Celebrating 15 Years of the Xen Project and Our Future by fbifido
https://blog.xenproject.org/2018/10/23/celebrating-15-years-of-the-xen-project-and-our-future/#comment-563

future point 3:
if you can get Xen booted in under 10 seconds, then how about trying to put Xen in server or pc BIOS/UEFI or onboard EPROM.
I am sure you can talk Intel/IBM/AMD to create a new onboard UEFI/BIOS chip that uses 3D-NVDIMM & NVMe, that way the pc/server only has one bios/efi and that is Xen.

thanks.

XSA-282 does not affect the security of Qubes OS
https://www.qubes-os.org/news/2018/11/06/xsa-282-qubes-not-affected/

Dear Qubes Community,

The Xen Project has published Xen Security Advisory 282 (XSA-282). 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/#282

Qubes OS 3.2.1 has been released!
https://www.qubes-os.org/news/2018/11/12/qubes-321/

We’re pleased to announce the stable release of Qubes 3.2.1! As we previously
announced (https://www.qubes-os.org/news/2018/10/05/qubes-321-rc1/), this is the first and only planned point release for
version 3.2. Since no major problems were discovered with 3.2.1-rc1, this stable
release is not significantly different from the release candidate. Features:

Fedora 28 TemplateVM
Debian 9 TemplateVM
Whonix 14 Gateway and Workstation TemplateVMs
Linux kernel 4.14
Release 3.2.1 has replaced Release 3.2 on the Downloads (https://www.qubes-os.org/downloads/) page.

What is a point release?

A point release does not designate a separate, new version of Qubes OS.
Rather, it designates its respective major or minor release (in this
case, 3.2) inclusive of all updates up to a certain point. Installing
Qubes 3.2 and fully updating it results in the same system as installing
Qubes 3.2.1.

What should I do?

If you’re currently using an up-to-date Qubes 3.2 installation, then
your system is already equivalent to a Qubes 3.2.1 installation. No
action is needed.

Regardless of your current OS, if you wish to install (or reinstall)
Qubes 3.2 for any reason, then the 3.2.1 ISO will make this more
convenient and secure, since it bundles all Qubes 3.2 updates to date.
It will be especially helpful for users whose hardware is too new to be
compatible with the original Qubes 3.2 installer.

As a reminder, Qubes 3.2 (and, therefore, Qubes 3.2.1) is scheduled to
reach EOL (end-of-life) on 2019-03-28 (https://www.qubes-os.org/doc/supported-versions/#qubes-os).

What about Qubes 4.0.1?

We recently announced the release of 4.0.1-rc1 (https://www.qubes-os.org/news/2018/11/05/qubes-401-rc1/). You can help us test (https://www.qubes-os.org/doc/testing/) this
release candidate and report any bugs you encounter (https://www.qubes-os.org/doc/reporting-bugs/) so that they can be fixed
before the stable release.

Comment on Celebrating 15 Years of the Xen Project and Our Future by fbifido
https://blog.xenproject.org/2018/10/23/celebrating-15-years-of-the-xen-project-and-our-future/#comment-565

future point 4:

1) you need to have storage backbone use RDMA & SR-IOV in the core of Xen.
2) you need to look at hyper-converge, make sure the foundation in bake into Xen core, see #1 above.

thanks.

Comment on Celebrating 15 Years of the Xen Project and Our Future by fbifido
https://blog.xenproject.org/2018/10/23/celebrating-15-years-of-the-xen-project-and-our-future/#comment-566

future point 5:

1) Support 2 version of Xen:
a. A long-term support option, 5 to 9 years.
b. and An always updated version, 6-12 months.
2) Version numbers by year-month_day
eg: Xen-2018-11_15

XSA-276, XSA-277, and XSA-279 do not affect the security of Qubes OS
https://www.qubes-os.org/news/2018/11/19/xsa-276-277-279-qubes-not-affected/

The Xen Project has published Xen Security Advisories 276, 277, and 279
(XSA-276, XSA-277, and XSA-279, 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/#276
https://www.qubes-os.org/security/xsa/#277
https://www.qubes-os.org/security/xsa/#279

QSB #44: Multiple Xen vulnerabilities (XSA-275, XSA-280)
https://www.qubes-os.org/news/2018/11/20/qsb-44/

We have just published Qubes Security Bulletin (QSB) #44: Multiple Xen
vulnerabilities (XSA-275, XSA-280). 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 #44 in the qubes-secpack:

https://github.com/QubesOS/qubes-secpack/blob/master/QSBs/qsb-044-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-275 and XSA-280 in the XSA Tracker:

https://www.qubes-os.org/security/xsa/#275
https://www.qubes-os.org/security/xsa/#280



---===[ Qubes Security Bulletin #44 ]===---

2018-11-20

Multiple Xen vulnerabilities (XSA-275, XSA-280)

Summary
========

On 2018-11-20, the Xen Security Team published multiple Xen Security
Advisories (XSAs):

XSA-275 [1] "insufficient TLB flushing / improper large page mappings
with AMD IOMMUs":
| In order to be certain that no undue access to memory is possible
| anymore after IOMMU mappings of this memory have been removed,
| Translation Lookaside Buffers (TLBs) need to be flushed after most
| changes to such mappings. Xen bypassed certain IOMMU flushes on AMD
| x86 hardware.
|
| Furthermore logic exists Xen to re-combine small page mappings
| into larger ones. Such re-combination could have occured in cases
| when it was not really safe/correct to do so.
|
| A malicious or buggy guest may be able to escalate its privileges, may
| cause a Denial of Service (DoS) affecting the entire host, or may be
| able to access data it is not supposed to access (information leak).

XSA-275 affects only AMD CPUs using IOMMU on both Qubes OS 3.2 and Qubes
OS 4.0. XSA-275 does not affect Intel CPUs on any Qubes OS version.

XSA-280 [2] "Fix for XSA-240 conflicts with shadow paging":
| The fix for XSA-240 introduced a new field into the control structure
| associated with each page of RAM. This field was added to a union,
| another member of which is used when Xen uses shadow paging for the
| guest. During migration, or with the L1TF (XSA-273) mitigation for
| PV guests in effect, the two uses conflict.
|
| A malicious or buggy x86 PV guest may cause Xen to crash, resulting in
| a DoS (Denial of Service) affecting the entire host. Privilege
| escalation as well as information leaks cannot be ruled out.

XSA-280 affects only Qubes OS 3.2. XSA-280 does not affect Qubes OS 4.0,
since the shadow paging feature is disabled at build time for 4.0.

Patching
=========

The specific packages that resolve the problems discussed in this
bulletin are as follows:

For Qubes OS 3.2:
- Xen packages, version 4.6.6-45

For Qubes OS 4.0:
- Xen packages, version 4.8.4-7

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-275.html
[2] https://xenbits.xen.org/xsa/advisory-280.html

--
The Qubes Security Team
https://www.qubes-os.org/security/

Fedora 27 has reached EOL
https://www.qubes-os.org/news/2018/11/30/fedora-27-eol/

The Fedora Project announced today that Fedora 27 has reached EOL
(end-of-life (https://fedoraproject.org/wiki/Fedora_Release_Life_Cycle#Maintenance_Schedule)). We strongly recommend that all Qubes users upgrade
their Fedora 27 TemplateVMs and StandaloneVMs to Fedora 28 immediately.
We provide step-by-step upgrade instructions for upgrading from Fedora
27 to 28 (https://www.qubes-os.org/doc/template/fedora/upgrade-27-to-28/). 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 Fedora 28 TemplateVM package through the
official Qubes repositories, which you can install in dom0 by following
the standard installation instructions (https://www.qubes-os.org/doc/templates/fedora/#installing).

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 27 to 28 (https://www.qubes-os.org/doc/template/fedora/upgrade-27-to-28/).

Please note that no user action is required regarding the OS version in
dom0. For details, please see our Note on dom0 and EOL (https://www.qubes-os.org/doc/supported-versions/#note-on-dom0-and-eol).