Qubes OS 4.0.4-rc1 has been released!
https://www.qubes-os.org/news/2020/11/05/qubes-4-0-4-rc1/

We’re pleased to announce the first release candidate for Qubes OS
4.0.4.

Qubes OS 4.0.4-rc1 includes many updates over the initial 4.0 release,
in particular:

All 4.0 dom0 updates to date
Fedora 32 TemplateVM
Debian 10 TemplateVM
Whonix 15 Gateway and Workstation TemplateVMs
Linux kernel 4.19 by default
Qubes 4.0.4-rc1 is available 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, 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.4.

What should I do?

If you installed Qubes 4.0, 4.0.1, 4.0.2, or 4.0.3 and have fully
updated (https://www.qubes-os.org/doc/updating-qubes-os/), then your system is already equivalent to a Qubes 4.0.4
installation. No further action is required.

Regardless of your current OS, if you wish to install (or reinstall)
Qubes 4.0 for any reason, then the 4.0.4 ISO makes this more convenient
and secure, since it bundles all Qubes 4.0 updates to date. Please see
the installation guide (https://www.qubes-os.org/doc/installation-guide/) for detailed instructions.

If you’re willing to test (https://www.qubes-os.org/doc/testing/) this release candidate, you can help to
improve the stable release by reporting any bugs you encounter (https://www.qubes-os.org/doc/reporting-bugs/).

Release candidate planning

If no major issues are discovered in 4.0.4-rc1, we expect to announce
the stable release of 4.0.4 in a couple weeks.

Design Session – Xen FuSA SIG present and future
https://xenproject.org/2020/11/06/design-session-xen-fusa-sig-present-and-future/

In this Xen Summit Design Session, the Xen Functional Safety Special Interest Group (FuSA SIG), outlines the progress of the group around Xen and Certification, what is currently being done,...

QSB #061: Information leak via power sidechannel (XSA-351)
https://www.qubes-os.org/news/2020/11/10/qsb-061/

We have just published Qubes Security Bulletin (QSB) #061:
Information leak via power sidechannel (XSA-351).
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 #061 in the qubes-secpack:

https://github.com/QubesOS/qubes-secpack/blob/master/QSBs/qsb-061-2020.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-351 in the XSA Tracker:

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



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

2020-11-10


Information leak via power sidechannel (XSA-351)


Summary
========

On 2020-11-10, the Xen Security Team published Xen Security Advisory
351 (XSA-351) [1] with the following denoscription:

| Researchers have demonstrated using software power/energy monitoring
| interfaces to create covert channels, and infer the operations/data used
| by other contexts within the system.
|
| Access to these interfaces should be restricted to privileged software,
| but it was found that Xen doesn't restrict access suitably, and the
| interfaces are accessible to all guests.
|
| For more information, see:
| https://platypusattack.com
| https://www.intel.com/content/www/us/en/security-center/advisory/intel-sa-00389.html
|
| An unprivileged guest administrator can sample platform power/energy
| data. This may be used to infer the operations/data used by other
| contexts within the system.
|
| The research demonstrates using this sidechannel to leak the AES keys
| used elsewhere in the system.


Patching
=========

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

For Qubes 4.0:
- Xen packages, version 4.8.5-26
For Qubes 4.1:
- Xen packages, version 4.14.0-7

The packages are to be installed in dom0 via the Qube 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-351.html

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

QSB #062: Stack corruption from XSA-346 change (XSA-355)
https://www.qubes-os.org/news/2020/11/24/qsb-062/

We have just published Qubes Security Bulletin (QSB) #062:
Stack corruption from XSA-346 change (XSA-355).
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 #062 in the qubes-secpack:

https://github.com/QubesOS/qubes-secpack/blob/master/QSBs/qsb-062-2020.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-355 in the XSA Tracker:

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



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

2020-11-24


Stack corruption from XSA-346 change (XSA-355)


Summary
========

On 2020-11-24, the Xen Security Team published Xen Security Advisory
355 (XSA-355) [1] with the following denoscription:

| One of the two changes for XSA-346 introduced an on-stack array. The
| check for guarding against overrunning this array was off by one,
| allowing for corruption of the first stack slot immediately following
| this array.
|
| A malicious or buggy HVM or PVH guest can cause Xen to crash, resulting
| in a Denial of Service (DoS) to the entire host. Privilege escalation
| as well as information leaks cannot be excluded.


Patching
=========

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

For Qubes 4.0:
- Xen packages, version 4.8.5-27
For Qubes 4.1:
- Xen packages, version 4.14.0-8

The packages are to be installed in dom0 via the Qube 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-355.html

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

Qubes Survey: The Results
https://www.qubes-os.org/news/2020/11/26/qubes-survey-results/

Hello, lovely Qubes Community!

A couple of weeks ago, we asked you to participate in a survey; to our delight and surprise, over 2100 of you decided to help us and filled it out!
We are grateful for our wonderful community and wanted to share some interesting findings from the survey with you.
A small statistical note: a survey such as this, on a non-random and very much self-selected sample, is not necessarily completely representative of the whole community.
It’s quite possible that the people whom we did not reach and the people who decided not the participate in the survey differ in statistical ways from those we did survey, so please understand all of the “community members say X” statements below as having a little asterisk with “as far as we know based on this survey”.

Some introductory stats: 54% percent of our respondents have Qubes installed, and 22% are planning to.

Most of them are expert computer users to varying degrees, but 1% said that they prefer not to use computers when they don’t have to.
Seeing the state of security in the wide computer world, sometimes we’re tempted to agree.

It also turned out that our community has a fairly unsurprising age spread, with almost half (43%) of the respondents between 18 and 34 and a third (31%) between 35 and 49.
There are people over 70 and under 18 among us, too.

About one-third of the respondents are developers (which is in line with what we anticipated — after all, Qubes is a pretty technical piece of software), and IT professionals of all sorts are about sixty percent of the respondents.
We also have a strong contingent of academics (19%) and activists (16%).

For privacy reasons, we won’t be sharing a detailed breakdown of where our users are located, but we made a map with countries colored based on how many Qubes users are there, for your and our enjoyment.
Note: the map is based on Wikipedia’s map of the world. Please forgive any inaccuracies in it.

While doing the data crunching, I was a bit fascinated by three large groups of people: those from capital cities just putting down the name of the capital (omitting the country name), people in the US replying with just the name of their town (I’ve learned a lot about small American towns!) and people in the UK clarifying they are not English, thank you very much.
I had to smile at “United Kingdom of England and Some Actually Good Countries”.

We’re very interested in the hardware people are using and want to use with Qubes. Hardware is always a difficult subject for us, as there’s a lot of possible combinations and not nearly enough manpower to test and fix bugs for all of them, and we want to know where to focus our resources.
This intuition was well confirmed by the survey: hardware compatibility was something a lot of people mentioned in the “reasons for not using Qubes/reasons for stopping using Qubes” questions.

Following the common trend in modern hardware, most people use laptops or laptops and desktops equally (only 22% of our respondents use mostly a desktop computer), and most Qubes users tend to use it on a laptop (63% of them in the survey).
A lot of people use external monitors with their laptops (over 55% of laptop users), and we know an external monitor can be tricky to use with Qubes, leading to all sorts of annoying problems with layout or input detection. (If you haven’t yet tried it, take a look here: Qubes GUI Troubleshooting (https://www.qubes-os.org/doc/gui-troubleshooting/)).
A significant number of respondents also say they use cameras (36%) and microphones (60%). It makes me wonder what the responses to this question would be a year ago, before so many of us started working remotely.

As far as desired Qubes localization goes, there were few surprises, with the overwhelming majority preferring English (for a survey in English, it’s hard to be shocked by this result), and the next places being taken by German (over 200 votes), French (over 120 votes), Spanish (over 80) and Russian (over 70).
One impressive polyglot said they use a different language in each AppVM to easily distinguish their working environments, and I have to say, I wish I spoke enough languages to achieve that!

We asked about the OS our respondents find most comfortable, and, clearly, most prefer using Linux (48%), with Windows and Qubes (about 21% each) close seconds.
Finally, there’s little love for Mac OS, with less than 10% of respondents listing it as “most comfortable”.
Among Linux users, the range of distributions wasn’t very surprising, with Debian and Ubuntu as clear leaders, with over 50% selecting each as the distribution they use.

We also asked about the distribution you would prefer as the default template for AppVMs.
Debian got over twice as many votes (686) as the runner-up, Fedora (336).
Sounds like a good moment to mention that in Qubes 4.1 you can choose the default template at install (currently between Fedora and Debian).
Arch Linux (third place, with 74 people writing it in as ‘Other’) is also available as a community template and is well-maintained.
Interestingly enough, just using a distribution doesn’t mean someone wants to use it as the default template in Qubes, with some distributions having much more ardent supporters.
82% of people who use Debian want it as the default template, which is not that surprising, as Debian was one of the options explicitly offered in the “default distro” question.
But also almost 50% of NixOS users want it as the default template, which even from a purely methodological point of view is a lot, as they had to explicitly write this distribution down in the second question.
NixOS has some very devoted users!
On the other hand, although Ubuntu was one of the most popular distributions, only 4% of its users wrote it as their preferred default distribution…

Distribution
Users
Want it as default template
Debian
1103
82%
Ubuntu

928
4%
Fedora
783
55%
Arch Linux
438
23%
CentOS
265
6%
Gentoo
86
34%
NixOS
46
46%
(This table contains only the most popular choices, not all answers.)

From a UX development point of view, a particularly important question for us was “How many qubes do you typically run at the same time?”
Turns out that about the same number of people run 3-5 qubes as 6-10 (about 38%).
This will definitely be a huge help in future development of the various Qubes tools and widgets. It’s also a bit more than we suspected before!

As far the “how did you learn about Qubes” questions go, I think the conclusion on my side (as one of the authors of the survey) is simple: I really should have just included a “from Edward Snowden” option there, which would have saved our respondents some typing!

The survey covered many more questions than are described above, and they are all important for us as a team to learn more about you, our users, to know what to focus on and what to work on, what will work best and what may not be a great idea.
Don’t worry. If a question isn’t discussed above, we have still read it!
And again, thank you everyone for participating (and the many, many kind words you shared in your surveys).

Qubes Canary 025
https://www.qubes-os.org/news/2020/12/12/canary-025/

We have published Qubes Canary 025. The text of this canary is
reproduced below.

Note: We have decided to make some minor formatting changes to the way
Qubes Canary and Qubes Security Bulletin (QSB) numbers are printed,
such as dropping the ‘#’ symbol and using hyphens instead of spaces.

This canary and its accompanying signatures will always be available in
the Qubes Security Pack (qubes-secpack).

View Qubes Canary 025 in the qubes-secpack:

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


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

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

1. The date of issue of this canary is December 8, 2020.

2. There have been 62 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 March 2020. 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
-------------------

Tue, 08 Dec 2020 16:46:42 +0000

Source: DER SPIEGEL - International (https://www.spiegel.de/international/index.rss)
Dangerous Accusations: German Tennis Star Alexander Zverev Faces Career Turning Point
Skiing in the Pandemic: Alpine Rivalries Flare amid Resort Closures
Biden's Goal of Saving the Iran Deal Just Got Harder - A Murder and an Ultimatum
Heiko Maas: Germany's Foreign Minister on the Future of Trans-Atlantic Relations
Generation Corona: The Pandemic Is Changing Our Children's Lives for the Worse

Source: NYT > World News (https://rss.nytimes.com/services/xml/rss/nyt/World.xml)
Covid-19 Live Updates: Britain Begins Vaccinating Citizens
U.K. Covid Vaccine: Side Effects, Safety, and Who Gets It First
U.S. Leaves Behind Afghan Bases — and a Legacy of Land Disputes
Covid Infections, and Blame, Rise Along Southeast Asian Borders
U.S. Imposes Sanctions on Chinese Officials Over Hong Kong Crackdown

Source: BBC News - World (https://feeds.bbci.co.uk/news/world/rss.xml)
Safety data on Pfizer jab released by US
Lloyd Austin: Biden picks ex-general as defence secretary
The man saving monkeys in the Colombian Amazon

Charlie Hebdo attack: France seeks long jail terms in Paris trial
Christchurch massacre: Inquiry finds failures ahead of attack

Source: Blockchain.info
0000000000000000000c6550025327ca735099e0c621a9ad4599a49dab41f573

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!

HVMI: Security Solutions Thrive on Friendly Hypervisors
https://xenproject.org/2020/12/14/hvmi-security-solutions-thrive-on-friendly-hypervisors/

This talk was given by Raul Tosa & Daniel Ticle, Bitdefender at the Xen Developer and Design Summit in July 2020. In July, Bitdefender open sourced Hypervisor Memory Introspection (HVMI)....

QSB-063: Multiple Xen issues (XSA-115, XSA-325, XSA-350)
https://www.qubes-os.org/news/2020/12/16/qsb-063/

We have just published Qubes Security Bulletin (QSB) 063:
Stack corruption from XSA-346 change (XSA-355).
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-063 in the qubes-secpack:

https://github.com/QubesOS/qubes-secpack/blob/master/QSBs/qsb-063-2020.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 all XSAs mentioned in this QSB in the XSA Tracker:

https://www.qubes-os.org/security/xsa/



---===[ Qubes Security Bulletin 063 ]===---

2020-12-15


Multiple Xen issues (XSA-115, XSA-325, XSA-350)


User action required
=====================

Users must install the following specific packages in order to address
the issues discussed in this bulletin:

For Qubes 4.0:
- Xen packages, version 4.8.5-28
- Linux kernel packages, versions 5.9.14-1, 5.4.83-1, 4.19.163-1

For Qubes 4.1:
- Xen packages, version 4.14.0-9
- Linux kernel packages, versions 5.9.14-1, 5.4.83-1, 4.19.163-1

The packages are to be installed in dom0 via the Qube 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.


Summary
========

On 2020-12-15, the Xen Security Team published the following Xen
Security Advisories (XSAs):

XSA-115 [1] "xenstore watch notifications lacking permission checks"
| Neither xenstore implementation does any permissions checks when
| reporting a xenstore watch event.
|
| A guest administrator can watch the root xenstored node, which will
| cause notifications for every created, modified and deleted key.
|
| A guest administrator can also use the special watches, which will
| cause a notification every time a domain is created and destroyed.
|
| Data may include:
| - number, type and domids of other VMs
| - existence and domids of driver domains
| - numbers of virtual interfaces, block devices, vcpus
| - existence of virtual framebuffers and their backend style (eg,
| existence of VNC service)
| - Xen VM UUIDs for other domains
| - timing information about domain creation and device setup
| - some hints at the backend provisioning of VMs and their devices
|
| The watch events do not contain values stored in xenstore, only key
| names.

XSA-325 [2] "Xenstore: guests can disturb domain cleanup"
| Xenstored and guests communicate via a shared memory page using a
| specific protocol. When a guest violates this protocol, xenstored will
| drop the connection to that guest.
|
| Unfortunately this is done by just removing the guest from xenstored's
| internal management, resulting in the same actions as if the guest had
| been destroyed, including sending an @releaseDomain event.
|
| @releaseDomain events do not say guest has been removed. All watchers
| of this event must look at the states of all guests to find the guest
| which has been removed. When an @releaseDomain is generated due to
| domain xenstored protocol violation, As the guest is still running, so
| the watchers will not react.
|
| Later, when the guest is actually destroyed, xenstored will no longer