QSB-066: XML injection through libvirt domain configuration
https://www.qubes-os.org/news/2021/03/03/qsb-066/
We have just published Qubes Security Bulletin (QSB) 066:
XML injection through libvirt domain configuration.
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-066 in the qubes-secpack:
https://github.com/QubesOS/qubes-secpack/blob/master/QSBs/qsb-066-2021.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 066 ]===---
2021-03-03
XML injection through libvirt domain configuration
User action required
=====================
Users must install the following specific packages in order to address
the issues discussed in this bulletin:
For Qubes 4.0:
- qubes-core-dom0 package, version 4.0.58-1
For Qubes 4.1:
- qubes-core-dom0 package, version 4.1.20-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. Alternatively, it is
possible to restart qubesd with the following command in dom0:
$ systemctl restart qubesd.service
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.
Summary
========
The libvirt domain configuration is an XML file built by filling a
template with values specific to a particular domain -- mostly its
properties but, in a few cases, "features" (extra properties that can be
freely defined). While most of the properties have strictly-defined
formats, some allow for a very broad range of values -- broad enough to
allow characters that are otherwise special in XML. Using such
characters in XML values requires escaping them, which was not enabled
in the template engine we use (jinja2). The specific VM metadata
properties that allow free text and are used in libvirt XML are as
follows:
- `kernelopts` property
- `timezone` feature (although it is validated in the template itself)
- `video-model` feature
- `audio-model` feature (Qubes R4.1 only)
Normally, this wouldn't be an issue, since all VM settings come from a
trusted entity (dom0). However, with the introduction of the Admin API
[1] in Qubes 4.0, it is possible to allow less trusted domains (known as
"ManagementVMs") to manage a subset of VMs or their settings, including
the affected properties and features. This, in turn, can be used to
modify unintended parts of the libvirt XML. In the worst case, this
could lead to code execution in dom0.
To fix the issue, we're enabling the autoescape feature of the jinja2
template engine. This will cover the current problematic properties as
well as any others that might be introduced in the future. Additionally,
we're adding an extra validation step for "features" that are otherwise
used in a free text form context (specifically, `net.fake-*` features
are expected to be IP addresses, but they lacked such validation).
Note that a ManagementVM can still break a VM it has control over, for
example, by setting some property to an improper value in a given
context (e.g., too little memory or too short of a startup timeout).
However, after these changes, it should no longer be able to escalate
its permissions beyond what it has been assigned.
Impact
=======
Default Qubes 4.0 and 4.1 configurations are not affected.
If a less trusted domain (known as a "ManagementVM") is given Admin API
https://www.qubes-os.org/news/2021/03/03/qsb-066/
We have just published Qubes Security Bulletin (QSB) 066:
XML injection through libvirt domain configuration.
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-066 in the qubes-secpack:
https://github.com/QubesOS/qubes-secpack/blob/master/QSBs/qsb-066-2021.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 066 ]===---
2021-03-03
XML injection through libvirt domain configuration
User action required
=====================
Users must install the following specific packages in order to address
the issues discussed in this bulletin:
For Qubes 4.0:
- qubes-core-dom0 package, version 4.0.58-1
For Qubes 4.1:
- qubes-core-dom0 package, version 4.1.20-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. Alternatively, it is
possible to restart qubesd with the following command in dom0:
$ systemctl restart qubesd.service
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.
Summary
========
The libvirt domain configuration is an XML file built by filling a
template with values specific to a particular domain -- mostly its
properties but, in a few cases, "features" (extra properties that can be
freely defined). While most of the properties have strictly-defined
formats, some allow for a very broad range of values -- broad enough to
allow characters that are otherwise special in XML. Using such
characters in XML values requires escaping them, which was not enabled
in the template engine we use (jinja2). The specific VM metadata
properties that allow free text and are used in libvirt XML are as
follows:
- `kernelopts` property
- `timezone` feature (although it is validated in the template itself)
- `video-model` feature
- `audio-model` feature (Qubes R4.1 only)
Normally, this wouldn't be an issue, since all VM settings come from a
trusted entity (dom0). However, with the introduction of the Admin API
[1] in Qubes 4.0, it is possible to allow less trusted domains (known as
"ManagementVMs") to manage a subset of VMs or their settings, including
the affected properties and features. This, in turn, can be used to
modify unintended parts of the libvirt XML. In the worst case, this
could lead to code execution in dom0.
To fix the issue, we're enabling the autoescape feature of the jinja2
template engine. This will cover the current problematic properties as
well as any others that might be introduced in the future. Additionally,
we're adding an extra validation step for "features" that are otherwise
used in a free text form context (specifically, `net.fake-*` features
are expected to be IP addresses, but they lacked such validation).
Note that a ManagementVM can still break a VM it has control over, for
example, by setting some property to an improper value in a given
context (e.g., too little memory or too short of a startup timeout).
However, after these changes, it should no longer be able to escalate
its permissions beyond what it has been assigned.
Impact
=======
Default Qubes 4.0 and 4.1 configurations are not affected.
If a less trusted domain (known as a "ManagementVM") is given Admin API
access to set any of the affected properties or features on any domain
(via the `admin.vm.property.Set` or `admin.vm.feature.Set` qrexec
services), it may use this access to elevate its privileges and
potentially take full control of the system.
Note that `qubes.FeaturesRequest` is enabled by default but *is not*
vulnerable for three reasons. First, feature names are read from
qubesd, which enforces a whitelist of permitted characters in paths.
None of the permitted characters are metacharacters in XML. Second,
none of the features for which dom0 will honor a request have their
values incorporated into libvirt XML. Third, `qubes.FeaturesRequest`
can only unset a feature or set its value to `1`.
Credits
========
This issue was discovered by Demi Marie Obenour.
References
===========
[1] https://www.qubes-os.org/doc/admin-api/
--
The Qubes Security Team
https://www.qubes-os.org/security/
(via the `admin.vm.property.Set` or `admin.vm.feature.Set` qrexec
services), it may use this access to elevate its privileges and
potentially take full control of the system.
Note that `qubes.FeaturesRequest` is enabled by default but *is not*
vulnerable for three reasons. First, feature names are read from
qubesd, which enforces a whitelist of permitted characters in paths.
None of the permitted characters are metacharacters in XML. Second,
none of the features for which dom0 will honor a request have their
values incorporated into libvirt XML. Third, `qubes.FeaturesRequest`
can only unset a feature or set its value to `1`.
Credits
========
This issue was discovered by Demi Marie Obenour.
References
===========
[1] https://www.qubes-os.org/doc/admin-api/
--
The Qubes Security Team
https://www.qubes-os.org/security/
Qubes OS 4.0.4 has been released!
https://www.qubes-os.org/news/2021/03/04/qubes-4-0-4/
We’re pleased to announce the release of Qubes OS 4.0.4! This is the
fourth stable release of Qubes 4.0. It includes many updates over the
initial 4.0 release, including:
All 4.0 dom0 updates to date
Fedora 32 TemplateVM
Debian 10 TemplateVM
Whonix 15 Gateway and Workstation TemplateVMs
Linux kernel 5.4 by default
Qubes 4.0.4 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 (https://www.qubes-os.org/doc/updating-qubes-os/) 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.
Thank you to all the release candidate users for testing this release
and reporting issues (https://www.qubes-os.org/doc/reporting-bugs/)!
https://www.qubes-os.org/news/2021/03/04/qubes-4-0-4/
We’re pleased to announce the release of Qubes OS 4.0.4! This is the
fourth stable release of Qubes 4.0. It includes many updates over the
initial 4.0 release, including:
All 4.0 dom0 updates to date
Fedora 32 TemplateVM
Debian 10 TemplateVM
Whonix 15 Gateway and Workstation TemplateVMs
Linux kernel 5.4 by default
Qubes 4.0.4 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 (https://www.qubes-os.org/doc/updating-qubes-os/) 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.
Thank you to all the release candidate users for testing this release
and reporting issues (https://www.qubes-os.org/doc/reporting-bugs/)!
XSAs released on 2021-03-04
https://www.qubes-os.org/news/2021/03/04/xsas-released-on-2021-03-04/
The Xen Project released one or more new Xen Security Advisories (XSAs) on 2021-03-04.
The security of Qubes OS is not affected by these XSAs.
Therefore, no user action is required.
XSAs that affect the security of Qubes OS (user action required)
The following XSAs do affect the security of Qubes OS:
(None)
XSAs that do not affect the security of Qubes OS (no user action required)
The following XSAs do not affect the security of Qubes OS, and no user action is necessary:
XSA-367 (not affected; Qubes uses PVH/HVM)
XSA-369 (DoS only)
Related links
Qubes Security Pack (qubes-secpack) (https://www.qubes-os.org/security/pack/)
Qubes Security Bulletins (QSBs) (https://www.qubes-os.org/security/bulletins/)
XSA Tracker (https://www.qubes-os.org/security/xsa/)
https://www.qubes-os.org/news/2021/03/04/xsas-released-on-2021-03-04/
The Xen Project released one or more new Xen Security Advisories (XSAs) on 2021-03-04.
The security of Qubes OS is not affected by these XSAs.
Therefore, no user action is required.
XSAs that affect the security of Qubes OS (user action required)
The following XSAs do affect the security of Qubes OS:
(None)
XSAs that do not affect the security of Qubes OS (no user action required)
The following XSAs do not affect the security of Qubes OS, and no user action is necessary:
XSA-367 (not affected; Qubes uses PVH/HVM)
XSA-369 (DoS only)
Related links
Qubes Security Pack (qubes-secpack) (https://www.qubes-os.org/security/pack/)
Qubes Security Bulletins (QSBs) (https://www.qubes-os.org/security/bulletins/)
XSA Tracker (https://www.qubes-os.org/security/xsa/)
Xen Summit 2021 Updates
https://xenproject.org/2021/03/10/xen-summit-2021-updates/
2021 Xen Project Design and Developer Summit: Registration and CFP Open Now! We are so excited to announce that registration and Call for Proposals has officially opened for the Xen...
https://xenproject.org/2021/03/10/xen-summit-2021-updates/
2021 Xen Project Design and Developer Summit: Registration and CFP Open Now! We are so excited to announce that registration and Call for Proposals has officially opened for the Xen...
Qubes Canary 026
https://www.qubes-os.org/news/2021/03/11/canary-026/
Note: When preparing the announcement for this canary, we
discovered a typographical error in the noscript (the canary number “025”
had not been updated to “026”). However, one of the canary signers is
not available to re-sign an updated canary before the canary deadline.
Rather than invalidate this signer’s signature by updating the canary
text immediately, we have decided to proceed with this announcement
with the existing canary text, accompanied with this note explaining
the error. As soon as all signers are available, the error will be
fixed, and the updated canary will be re-signed by all parties. Thank
you for your understanding.
We have published Qubes Canary 026. 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 026 in the qubes-secpack:
https://github.com/QubesOS/qubes-secpack/blob/master/canaries/canary-026-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 March 7, 2021.
2. There have been 66 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 2021. 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
-------------------
Sun, 07 Mar 2021 14:11:21 +0000
Source: DER SPIEGEL - International (https://www.spiegel.de/international/index.rss)
Monitoring the Right Wing: German Officials Seek to Turn up the Heat on the AfD
John Bolton on Halkbank: “Trump Wanted To Make an Impression on Erdoğan”
RT Germany: Berlin Fears Growing Influence of Russian Propaganda Platform
Generation Lockdown: Schoolchildren Around the World Face a Steep Uphill Battle
Boom in Somaliland: A Miracle on the Horn of Africa
Source: NYT > World News (https://rss.nytimes.com/services/xml/rss/nyt/World.xml)
Colombia Seeks Justice for War Atrocities Via New Court
In Hong Kong, Foreign Tourists Are Replaced by a Local Variety
Pope Francis Meets Iraq’s Top Ayatollah as Both Urge Peace
https://www.qubes-os.org/news/2021/03/11/canary-026/
Note: When preparing the announcement for this canary, we
discovered a typographical error in the noscript (the canary number “025”
had not been updated to “026”). However, one of the canary signers is
not available to re-sign an updated canary before the canary deadline.
Rather than invalidate this signer’s signature by updating the canary
text immediately, we have decided to proceed with this announcement
with the existing canary text, accompanied with this note explaining
the error. As soon as all signers are available, the error will be
fixed, and the updated canary will be re-signed by all parties. Thank
you for your understanding.
We have published Qubes Canary 026. 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 026 in the qubes-secpack:
https://github.com/QubesOS/qubes-secpack/blob/master/canaries/canary-026-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 March 7, 2021.
2. There have been 66 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 2021. 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
-------------------
Sun, 07 Mar 2021 14:11:21 +0000
Source: DER SPIEGEL - International (https://www.spiegel.de/international/index.rss)
Monitoring the Right Wing: German Officials Seek to Turn up the Heat on the AfD
John Bolton on Halkbank: “Trump Wanted To Make an Impression on Erdoğan”
RT Germany: Berlin Fears Growing Influence of Russian Propaganda Platform
Generation Lockdown: Schoolchildren Around the World Face a Steep Uphill Battle
Boom in Somaliland: A Miracle on the Horn of Africa
Source: NYT > World News (https://rss.nytimes.com/services/xml/rss/nyt/World.xml)
Colombia Seeks Justice for War Atrocities Via New Court
In Hong Kong, Foreign Tourists Are Replaced by a Local Variety
Pope Francis Meets Iraq’s Top Ayatollah as Both Urge Peace
Chloé Zhao, ‘Nomadland’ Director, Encounters a Backlash in China
In a Land Dominated by Ex-Rebels, Kosovo Women Find Power at the Ballot Box
Source: BBC News - World (https://feeds.bbci.co.uk/news/world/rss.xml)
Pope Francis visits regions of Iraq once held by Islamic State
Uighurs: Chinese foreign minister says genocide claims 'absurd'
Nazanin Zaghari-Ratcliffe released but faces new court date
Myanmar coup: Party official dies in custody after security raids
US pastor on leave after Melania Trump 'trophy wife' comments
Source: Blockchain.info
000000000000000000021d96387dc5ac0d7b6b5567119ab8ae32de4351700136
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!
In a Land Dominated by Ex-Rebels, Kosovo Women Find Power at the Ballot Box
Source: BBC News - World (https://feeds.bbci.co.uk/news/world/rss.xml)
Pope Francis visits regions of Iraq once held by Islamic State
Uighurs: Chinese foreign minister says genocide claims 'absurd'
Nazanin Zaghari-Ratcliffe released but faces new court date
Myanmar coup: Party official dies in custody after security raids
US pastor on leave after Melania Trump 'trophy wife' comments
Source: Blockchain.info
000000000000000000021d96387dc5ac0d7b6b5567119ab8ae32de4351700136
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 is now a CVE Numbering Authority (CNA)
https://xenproject.org/2021/03/15/xen-project-is-now-a-cve-numbering-authority-cna/
The Common Vulnerability and Exposures (CVE) Program’s mission is to identify, define, and catalog publicly disclosed cybersecurity vulnerabilities. CVE numbers (assigned when vulnerabilities are added to the CVE List) enable...
https://xenproject.org/2021/03/15/xen-project-is-now-a-cve-numbering-authority-cna/
The Common Vulnerability and Exposures (CVE) Program’s mission is to identify, define, and catalog publicly disclosed cybersecurity vulnerabilities. CVE numbers (assigned when vulnerabilities are added to the CVE List) enable...
XenProject at Linaro Connect
https://xenproject.org/2021/03/16/xenproject-at-linaro-connect/
Linaro Virtual Connect 2021 provides a platform to discuss and learn about the leading software topics, challenges and opportunities in the Arm Ecosystem today. The event will have 60+ technical...
https://xenproject.org/2021/03/16/xenproject-at-linaro-connect/
Linaro Virtual Connect 2021 provides a platform to discuss and learn about the leading software topics, challenges and opportunities in the Arm Ecosystem today. The event will have 60+ technical...
XSAs released on 2021-03-18
https://www.qubes-os.org/news/2021/03/18/xsas-released-on-2021-03-18/
The Xen Project has released one or more new Xen Security Advisories (XSAs).
The security of Qubes OS is not affected by these XSAs.
Therefore, no user action is required.
XSAs that affect the security of Qubes OS (user action required)
The following XSAs do affect the security of Qubes OS:
(None)
XSAs that do not affect the security of Qubes OS (no user action required)
The following XSAs do not affect the security of Qubes OS, and no user action is necessary:
XSA-368 (DoS only)
Related links
Qubes Security Pack (qubes-secpack) (https://www.qubes-os.org/security/pack/)
Qubes Security Bulletins (QSBs) (https://www.qubes-os.org/security/bulletins/)
XSA Tracker (https://www.qubes-os.org/security/xsa/)
https://www.qubes-os.org/news/2021/03/18/xsas-released-on-2021-03-18/
The Xen Project has released one or more new Xen Security Advisories (XSAs).
The security of Qubes OS is not affected by these XSAs.
Therefore, no user action is required.
XSAs that affect the security of Qubes OS (user action required)
The following XSAs do affect the security of Qubes OS:
(None)
XSAs that do not affect the security of Qubes OS (no user action required)
The following XSAs do not affect the security of Qubes OS, and no user action is necessary:
XSA-368 (DoS only)
Related links
Qubes Security Pack (qubes-secpack) (https://www.qubes-os.org/security/pack/)
Qubes Security Bulletins (QSBs) (https://www.qubes-os.org/security/bulletins/)
XSA Tracker (https://www.qubes-os.org/security/xsa/)
QSB-067: Multiple RPM vulnerabilities
https://www.qubes-os.org/news/2021/03/19/qsb-067/
We have just published Qubes Security Bulletin (QSB) 067: Multiple RPM vulnerabilities.
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-067 in the qubes-secpack:
https://github.com/QubesOS/qubes-secpack/blob/master/QSBs/qsb-067-2021.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 067 ]===---
2021-03-19
Multiple RPM vulnerabilities
User action required
=====================
Users must install the following specific packages in order to address
the issues discussed in this bulletin:
For Qubes 4.0:
- rpm 4.14.2.1 (plus rebuilt packages to link with the new rpm)
- qubes-core-dom0-linux 4.0.29
- qubes-mgmt-salt-dom0-update 4.0.10
For Qubes 4.1:
- qubes-core-dom0-linux 4.1.10
- qubes-mgmt-salt-dom0-update 4.1.6
The packages are to be installed in dom0 via the Qubes Update tool [4]
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
After installing the updates in dom0, it is necessary to install updates
in Fedora-based TemplateVMs and StandaloneVMs. This can be
done via the Qubes Update tool [4] or using qubesctl (salt) as follows:
$ sudo qubesctl --skip-dom0 --templates --standalones state.sls update.qubes-vm
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.
Summary
========
Demi M. Obenour has discovered several issues in the RPM package
manager:
- CVE-2021-20271[1] RPM: Signature checks bypass via corrupted RPM
package
- CVE-2021-3421[2] RPM: unsigned signature header leads to string
injection into an RPM database
- CVE-2021-20266[3] RPM: missing length checks in hdrblobInit()
These issues allow an attacker who controls packages the user downloads
to inject malicious content that, under some conditions, may not be
detected by signature verification. Specifically, they allow the
attacker to modify parts of the package header that are not protected by
the signature and that are later integrated into the RPM database. This
allows for corrupting the RPM database and preventing further updates of
select packages. In the case of Fedora TemplateVMs, this also allows
for arbitrary code execution.
The CVE-2021-20271 exploit takes advantage of multiple headers in the
RPM package format. In a proper RPM package, the signature is placed in
a separate header (called the "signature header") and, if present, is
verified by librpm when loading the file (according to the requested
verification level). An RPM package also contains a "main header" that
includes all the other package metadata. The main header is protected by
a signature in the signature header. The payload is protected either by
a signature in the signature header or by a SHA-256 hash located in the
main header. The ability to distinguish between these two headers is
available to librpm internals but not to external librpm users.
A malformed package may contain a signature in the main header instead
of the signature header. Librpm will reject such a package only if a
strict signature check was requested. Otherwise, it will treat the
package as unsigned. DNF, on the other hand, has no way to check whether
the signature was in the correct header. It will load the package and,
seeing a signature, will assume that it was verified by librpm. This
https://www.qubes-os.org/news/2021/03/19/qsb-067/
We have just published Qubes Security Bulletin (QSB) 067: Multiple RPM vulnerabilities.
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-067 in the qubes-secpack:
https://github.com/QubesOS/qubes-secpack/blob/master/QSBs/qsb-067-2021.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 067 ]===---
2021-03-19
Multiple RPM vulnerabilities
User action required
=====================
Users must install the following specific packages in order to address
the issues discussed in this bulletin:
For Qubes 4.0:
- rpm 4.14.2.1 (plus rebuilt packages to link with the new rpm)
- qubes-core-dom0-linux 4.0.29
- qubes-mgmt-salt-dom0-update 4.0.10
For Qubes 4.1:
- qubes-core-dom0-linux 4.1.10
- qubes-mgmt-salt-dom0-update 4.1.6
The packages are to be installed in dom0 via the Qubes Update tool [4]
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
After installing the updates in dom0, it is necessary to install updates
in Fedora-based TemplateVMs and StandaloneVMs. This can be
done via the Qubes Update tool [4] or using qubesctl (salt) as follows:
$ sudo qubesctl --skip-dom0 --templates --standalones state.sls update.qubes-vm
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.
Summary
========
Demi M. Obenour has discovered several issues in the RPM package
manager:
- CVE-2021-20271[1] RPM: Signature checks bypass via corrupted RPM
package
- CVE-2021-3421[2] RPM: unsigned signature header leads to string
injection into an RPM database
- CVE-2021-20266[3] RPM: missing length checks in hdrblobInit()
These issues allow an attacker who controls packages the user downloads
to inject malicious content that, under some conditions, may not be
detected by signature verification. Specifically, they allow the
attacker to modify parts of the package header that are not protected by
the signature and that are later integrated into the RPM database. This
allows for corrupting the RPM database and preventing further updates of
select packages. In the case of Fedora TemplateVMs, this also allows
for arbitrary code execution.
The CVE-2021-20271 exploit takes advantage of multiple headers in the
RPM package format. In a proper RPM package, the signature is placed in
a separate header (called the "signature header") and, if present, is
verified by librpm when loading the file (according to the requested
verification level). An RPM package also contains a "main header" that
includes all the other package metadata. The main header is protected by
a signature in the signature header. The payload is protected either by
a signature in the signature header or by a SHA-256 hash located in the
main header. The ability to distinguish between these two headers is
available to librpm internals but not to external librpm users.
A malformed package may contain a signature in the main header instead
of the signature header. Librpm will reject such a package only if a
strict signature check was requested. Otherwise, it will treat the
package as unsigned. DNF, on the other hand, has no way to check whether
the signature was in the correct header. It will load the package and,
seeing a signature, will assume that it was verified by librpm. This
allows for bypassing package signature verification.
The other bugs (CVE-2021-20266, CVE-2021-3421) concern incorrect parsing
of the signature header (which, while it contains the signature, is
itself unsigned). These bugs lead either to crashing or to corrupting
the RPM database (if such a malformed package is installed).
While Fedora will release its own patches in due course, we apply a
mitigation that prevents the privilege escalation aspect of these
issues. We configure RPM to always verify package signatures, even if a
higher level package manager (like DNF) does not explicitly request it.
This way, bypassing the signature check in DNF is not enough to
compromise an entire TemplateVM. Note that this change also prevents the
installation of unsigned RPM packages, even when explicitly requested.
See the "Side effects" section below.
For the dom0 aspect of these issues in Qubes 4.0, we update RPM to a
version that is not vulnerable. We have decided to update to the next
major version of RPM (from 4.13 to 4.14). This is because, besides the
security fix itself (which could be backported), version 4.14 has
significantly improved integrity verification. In 4.14, the macro
_pkgverify_level can be used to require that all packages be signed by a
trusted key. It defaults to "digest", meaning that only checksums must
be present, but we have set it to "all", requiring that all packages be
signed. Additionally, the checks performed before importing a package
have been significantly enhanced, which substantially reduces the attack
surface prior to integrity verification.
In the near future, we will also deploy an extra tool to perform
preliminary validation of all RPM packages in dom0 before handing them
over to RPM.
Impact
=======
The impact differs between Fedora templates and dom0:
1. For Fedora templates, an attacker who controls packages that the user
downloads can completely bypass package signature verification and
fully compromise Fedora templates.
2. For dom0, an attacker who controls packages that the user downloads
can corrupt the RPM database and (almost silently) prevent further
updates of select packages.
The attack requires control over the contents of downloaded packages.
This requirement differs slightly between Fedora templates and dom0:
1. For Fedora templates, the attacker would either have to
a. compromise the Fedora infrastructure that is serving updates or
b. perform a man-in-the-middle attack on the HTTPS connection used to
download the repository metadata (which contains package hashes).
2. For dom0, the attacker would either have to attack the user's
repository access (as in the Fedora template case) or compromise the
UpdateVM (sys-firewall in the default configuration).
Side effects
=============
The mitigation forces signature verification in RPM regardless of other
options. This means that RPM will refuse to install packages that are
unsigned (or signed with an untrusted signature), even when explicitly
requested to do so. This breaks use cases such as installing
locally-built packages and installing manually-downloaded packages the
integrity of which was verified separately (which is often the case for
closed-source software).
In such cases, neither `dnf install /path/to/the/package.rpm` nor `rpm
-i /path/to/the/package.rpm` will work any longer. Instead, to install a
package without a trusted signature (that has been verified by other
means), use the following command:
rpm --define '_pkgverify_level digest' -i /path/to/the/package.rpm
If the package has any dependencies, the above command will list them,
and they will have to be installed with `dnf` manually.
Credits
========
These issues were discovered and reported by Demi M. Obenour.
References
===========
[1] https://bugzilla.redhat.com/show_bug.cgi?id=1934125
[2] https://bugzilla.redhat.com/show_bug.cgi?id=1927747
[3] https://bugzilla.redhat.com/show_bug.cgi?id=1927741
The other bugs (CVE-2021-20266, CVE-2021-3421) concern incorrect parsing
of the signature header (which, while it contains the signature, is
itself unsigned). These bugs lead either to crashing or to corrupting
the RPM database (if such a malformed package is installed).
While Fedora will release its own patches in due course, we apply a
mitigation that prevents the privilege escalation aspect of these
issues. We configure RPM to always verify package signatures, even if a
higher level package manager (like DNF) does not explicitly request it.
This way, bypassing the signature check in DNF is not enough to
compromise an entire TemplateVM. Note that this change also prevents the
installation of unsigned RPM packages, even when explicitly requested.
See the "Side effects" section below.
For the dom0 aspect of these issues in Qubes 4.0, we update RPM to a
version that is not vulnerable. We have decided to update to the next
major version of RPM (from 4.13 to 4.14). This is because, besides the
security fix itself (which could be backported), version 4.14 has
significantly improved integrity verification. In 4.14, the macro
_pkgverify_level can be used to require that all packages be signed by a
trusted key. It defaults to "digest", meaning that only checksums must
be present, but we have set it to "all", requiring that all packages be
signed. Additionally, the checks performed before importing a package
have been significantly enhanced, which substantially reduces the attack
surface prior to integrity verification.
In the near future, we will also deploy an extra tool to perform
preliminary validation of all RPM packages in dom0 before handing them
over to RPM.
Impact
=======
The impact differs between Fedora templates and dom0:
1. For Fedora templates, an attacker who controls packages that the user
downloads can completely bypass package signature verification and
fully compromise Fedora templates.
2. For dom0, an attacker who controls packages that the user downloads
can corrupt the RPM database and (almost silently) prevent further
updates of select packages.
The attack requires control over the contents of downloaded packages.
This requirement differs slightly between Fedora templates and dom0:
1. For Fedora templates, the attacker would either have to
a. compromise the Fedora infrastructure that is serving updates or
b. perform a man-in-the-middle attack on the HTTPS connection used to
download the repository metadata (which contains package hashes).
2. For dom0, the attacker would either have to attack the user's
repository access (as in the Fedora template case) or compromise the
UpdateVM (sys-firewall in the default configuration).
Side effects
=============
The mitigation forces signature verification in RPM regardless of other
options. This means that RPM will refuse to install packages that are
unsigned (or signed with an untrusted signature), even when explicitly
requested to do so. This breaks use cases such as installing
locally-built packages and installing manually-downloaded packages the
integrity of which was verified separately (which is often the case for
closed-source software).
In such cases, neither `dnf install /path/to/the/package.rpm` nor `rpm
-i /path/to/the/package.rpm` will work any longer. Instead, to install a
package without a trusted signature (that has been verified by other
means), use the following command:
rpm --define '_pkgverify_level digest' -i /path/to/the/package.rpm
If the package has any dependencies, the above command will list them,
and they will have to be installed with `dnf` manually.
Credits
========
These issues were discovered and reported by Demi M. Obenour.
References
===========
[1] https://bugzilla.redhat.com/show_bug.cgi?id=1934125
[2] https://bugzilla.redhat.com/show_bug.cgi?id=1927747
[3] https://bugzilla.redhat.com/show_bug.cgi?id=1927741
[4] https://www.qubes-os.org/doc/updating-qubes-os/
--
The Qubes Security Team
https://www.qubes-os.org/security/
--
The Qubes Security Team
https://www.qubes-os.org/security/
XSAs released on 2021-03-30
https://www.qubes-os.org/news/2021/03/30/xsas-released-on-2021-03-30/
The Xen Project has released one or more new Xen Security Advisories (XSAs).
The security of Qubes OS is not affected by these XSAs.
Therefore, no user action is required.
XSAs that affect the security of Qubes OS (user action required)
The following XSAs do affect the security of Qubes OS:
(None)
XSAs that do not affect the security of Qubes OS (no user action required)
The following XSAs do not affect the security of Qubes OS, and no user action is necessary:
XSA-371 (DoS only)
Related links
Qubes Security Pack (qubes-secpack) (https://www.qubes-os.org/security/pack/)
Qubes Security Bulletins (QSBs) (https://www.qubes-os.org/security/bulletins/)
XSA Tracker (https://www.qubes-os.org/security/xsa/)
https://www.qubes-os.org/news/2021/03/30/xsas-released-on-2021-03-30/
The Xen Project has released one or more new Xen Security Advisories (XSAs).
The security of Qubes OS is not affected by these XSAs.
Therefore, no user action is required.
XSAs that affect the security of Qubes OS (user action required)
The following XSAs do affect the security of Qubes OS:
(None)
XSAs that do not affect the security of Qubes OS (no user action required)
The following XSAs do not affect the security of Qubes OS, and no user action is necessary:
XSA-371 (DoS only)
Related links
Qubes Security Pack (qubes-secpack) (https://www.qubes-os.org/security/pack/)
Qubes Security Bulletins (QSBs) (https://www.qubes-os.org/security/bulletins/)
XSA Tracker (https://www.qubes-os.org/security/xsa/)
Xen Project Hypervisor 4.15 now Available
https://xenproject.org/2021/04/08/xen-project-hypervisor-4-15/
Xen Project ships version 4.15 with Focus on Broader Accessibility, Performance, and Security. New version introduces Processor Trace, Improved Viridian support. Community initiatives, including Functional Safety and RISC-V Port, continue...
https://xenproject.org/2021/04/08/xen-project-hypervisor-4-15/
Xen Project ships version 4.15 with Focus on Broader Accessibility, Performance, and Security. New version introduces Processor Trace, Improved Viridian support. Community initiatives, including Functional Safety and RISC-V Port, continue...
Get paid to support Qubes development through automated testing! (six-month contract)
https://www.qubes-os.org/news/2021/04/10/get-paid-to-support-qubes-development-through-automated-testing/
The Qubes OS Project is seeking an expert in automated testing. We use
OpenQA and Travis to test changes to the Qubes OS source code and
automated building from source. We’re looking for someone who can help
with improving both the automated tests themselves and the testing
infrastructure.
This is a paid position on a six-month part-time contract with a
budgeted rate of $30-50 USD per hour through the Internews BASICS
project (Building Analytical and Support Infrastructure for Critical
Security tools):
https://phf.tbe.taleo.net/phf04/ats/careers/v2/viewRequisition?cws=38&org=INTERNEWS&rid=1392
https://www.qubes-os.org/news/2021/04/10/get-paid-to-support-qubes-development-through-automated-testing/
The Qubes OS Project is seeking an expert in automated testing. We use
OpenQA and Travis to test changes to the Qubes OS source code and
automated building from source. We’re looking for someone who can help
with improving both the automated tests themselves and the testing
infrastructure.
This is a paid position on a six-month part-time contract with a
budgeted rate of $30-50 USD per hour through the Internews BASICS
project (Building Analytical and Support Infrastructure for Critical
Security tools):
https://phf.tbe.taleo.net/phf04/ats/careers/v2/viewRequisition?cws=38&org=INTERNEWS&rid=1392
Why Attend the 2021 Xen Project Design and Developer Summit?
https://xenproject.org/2021/05/18/why-attend-the-2021-xen-project-design-and-developer-summit/
It’s almost that time of year, where we gather together as a Xen Project community and geek out on one of our most favorite topics – The Xen Project, of...
https://xenproject.org/2021/05/18/why-attend-the-2021-xen-project-design-and-developer-summit/
It’s almost that time of year, where we gather together as a Xen Project community and geek out on one of our most favorite topics – The Xen Project, of...
Fedora 32 has reached EOL
https://www.qubes-os.org/news/2021/05/25/fedora-32-eol/
Fedora 32 has reached EOL (end-of-life (https://fedoraproject.org/wiki/End_of_life)). If you have not already done
so, we strongly recommend upgrading (https://www.qubes-os.org/doc/templates/fedora/#upgrading) your Fedora 32 TemplateVMs and
StandaloneVMs to Fedora 33 immediately. We provide a fresh Fedora 33
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). Alternatively, we also provide step-by-step instructions
for performing an in-place upgrade (https://www.qubes-os.org/doc/template/fedora/upgrade/) of an existing Fedora TemplateVM.
After upgrading your TemplateVMs, please remember to switch all qubes
that were using the old template to use the new one (https://www.qubes-os.org/doc/templates/#switching).
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).
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).
https://www.qubes-os.org/news/2021/05/25/fedora-32-eol/
Fedora 32 has reached EOL (end-of-life (https://fedoraproject.org/wiki/End_of_life)). If you have not already done
so, we strongly recommend upgrading (https://www.qubes-os.org/doc/templates/fedora/#upgrading) your Fedora 32 TemplateVMs and
StandaloneVMs to Fedora 33 immediately. We provide a fresh Fedora 33
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). Alternatively, we also provide step-by-step instructions
for performing an in-place upgrade (https://www.qubes-os.org/doc/template/fedora/upgrade/) of an existing Fedora TemplateVM.
After upgrading your TemplateVMs, please remember to switch all qubes
that were using the old template to use the new one (https://www.qubes-os.org/doc/templates/#switching).
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).
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).
NitroPad T430 passes hardware certification for Qubes 4.0!
https://www.qubes-os.org/news/2021/06/01/nitropad-t430-qubes-certification/
It is our pleasure to announce that the NitroPad T430 (https://shop.nitrokey.com/shop/product/nitropad-t430-119) has become the
third Qubes-certified Laptop (https://www.qubes-os.org/doc/certified-hardware/#qubes-certified-laptops) for Qubes 4.0! This makes
Nitrokey (https://www.nitrokey.com/) the first vendor to have two products that pass Qubes
hardware certification, the other being the NitroPad X230 (https://www.qubes-os.org/doc/certified-hardware/#nitropad-x230).
What is Qubes Certified Hardware?
Qubes Certified Hardware (https://www.qubes-os.org/doc/certified-hardware/) is hardware that has been certified by the
Qubes developers as compatible with Qubes OS. Beginning with Qubes 4.0,
in order to achieve certification, the hardware must satisfy a rigorous
set of requirements (https://www.qubes-os.org/doc/certified-hardware/#hardware-certification-requirements), and the vendor must commit to offering customers
the very same configuration (same motherboard, same screen, same BIOS
version, same Wi-Fi module, etc.) for at least one year.
Qubes-certified Laptops (https://www.qubes-os.org/doc/certified-hardware/#qubes-certified-laptops), in particular, are regularly tested
by the Qubes developers to ensure compatibility with all of Qubes’
features. The developers test all new major versions and updates to
ensure that no regressions are introduced.
It is important to note, however, that Qubes Hardware Certification
certifies only that a particular hardware configuration is supported
by Qubes. The Qubes OS Project takes no responsibility for any vendor’s
manufacturing, shipping, payment, or other practices, nor can we control
whether physical hardware is modified (whether maliciously or otherwise)
en route to the user. (However, see below for information about how
this risk is mitigated.)
About the NitroPad T430
https://www.qubes-os.org/news/2021/06/01/nitropad-t430-qubes-certification/
It is our pleasure to announce that the NitroPad T430 (https://shop.nitrokey.com/shop/product/nitropad-t430-119) has become the
third Qubes-certified Laptop (https://www.qubes-os.org/doc/certified-hardware/#qubes-certified-laptops) for Qubes 4.0! This makes
Nitrokey (https://www.nitrokey.com/) the first vendor to have two products that pass Qubes
hardware certification, the other being the NitroPad X230 (https://www.qubes-os.org/doc/certified-hardware/#nitropad-x230).
What is Qubes Certified Hardware?
Qubes Certified Hardware (https://www.qubes-os.org/doc/certified-hardware/) is hardware that has been certified by the
Qubes developers as compatible with Qubes OS. Beginning with Qubes 4.0,
in order to achieve certification, the hardware must satisfy a rigorous
set of requirements (https://www.qubes-os.org/doc/certified-hardware/#hardware-certification-requirements), and the vendor must commit to offering customers
the very same configuration (same motherboard, same screen, same BIOS
version, same Wi-Fi module, etc.) for at least one year.
Qubes-certified Laptops (https://www.qubes-os.org/doc/certified-hardware/#qubes-certified-laptops), in particular, are regularly tested
by the Qubes developers to ensure compatibility with all of Qubes’
features. The developers test all new major versions and updates to
ensure that no regressions are introduced.
It is important to note, however, that Qubes Hardware Certification
certifies only that a particular hardware configuration is supported
by Qubes. The Qubes OS Project takes no responsibility for any vendor’s
manufacturing, shipping, payment, or other practices, nor can we control
whether physical hardware is modified (whether maliciously or otherwise)
en route to the user. (However, see below for information about how
this risk is mitigated.)
About the NitroPad T430