QSB-106: Information disclosure through uninitialized memory in libxl
QSB-106: Information disclosure through uninitialized memory in libxl
We have published Qubes Security Bulletin (QSB) 106: Information disclosure through uninitialized memory in libxl. The text of this QSB and its accompanying cryptographic signatures are reproduced below, followed by a general explanation of this announcement and authentication instructions.
Qubes Security Bulletin 106
---===[ Qubes Security Bulletin 106 ]===---
2024-11-12
Information disclosure through uninitialized memory in libxl
(XSA-464)
Changelog
----------
2024-11-12: Original QSB
2024-11-29: Revise language
User action
------------
Continue to update normally [1] in order to receive the security updates
described in the "Patching" section below. No other user action is
required in response to this QSB.
Summary
--------
On 2024-11-12, the Xen Project published XSA-464, "libxl leaks data to PVH
guests via ACPI tables" (CVE-2024-45819) [3]:
| PVH guests have their ACPI tables constructed by the toolstack. The
| construction involves building the tables in local memory, which are
| then copied into guest memory. While actually used parts of the local
| memory are filled in correctly, excess space that is being allocated is
| left with its prior contents.
Qubes calls libxl via libvirtd. The memory that is not fully initialized
is allocated via malloc. So, the prior content that is leaked to a PVH
qube might be anything that has been previously allocated and
subsequently freed in the libvirtd process.
Impact
-------
The leaked memory usually doesn't contain important secrets, [4] but it
can reveal various information about other qubes and the host system
that would not otherwise be available to a malicious qube. In
particular, the following types of information might be present in
libvirtd's memory:
Information about other qubes:
- Name
- UUID
- kernel version
- kernel cmdline
- IP/MAC addresses of virtual network devices (but not from physical
devices) [5]
- Assigned PCI devices
Information about the host system:
- Total system memory
- Available PCI devices
- DMI/SYSBIOS information (serial number as reported by firmware, RAM
DIMM product number, etc.)
These lists are not intended to be exhaustive. For example, they don't
include less-interesting qube settings like the assigned audio qube, but
they should cover all the important categories.
Note that a malicious qube has very little control over the information
leaked in the uninitialized memory to which it is exposed. [6]
Additionally, the leak happens only once per qube boot, so for a decent
chance of being exposed to interesting information, a malicious qube may
have to wait a long time in order to be exposed to a significant number
of normal qube boots. Alternatively, a malicious qube could attempt to
provoke boots of disposable qubes it can control (for example, via
qubes.VMShell) or shut itself down and hope to be rebooted by the user
or a qrexec call. However, both of these methods would result in unusual
system activity that users would easily notice.
Affected systems
-----------------
All supported version of Qubes OS are affected.
Only qubes in PVH mode are affected. In the default configuration, this
includes all qubes except for sys-net and sys-usb.
Patching
---------
The following packages contain security updates that address the
vulnerabilities described in this bulletin:
For Qubes 4.2, in dom0:
- Xen packages, version 4.17.5-4
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. [2] Once available, the packages are to be installed
via the Qubes Update tool or its command-line equivalents. [1]
Dom0 must be restarted afterward in order for the updates to take
effect.
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://www.qubes-os.org/doc/how-to-update/
[2] https://www.qubes-os.org/doc/testing/
[3] https://xenbits.xen.org/xsa/advisory-464.html
[4] The leaked memory could reveal the ASLR secret of the libvirtd
process, but this is only useful when the attacker has knowledge of
a memory vulnerability in libvirtd/libxl that is reachable in Qubes
OS. Additionally, in an unusual custom setup, a user could have
included a secret in some of the leaked information about other
qubes.
[5] Unless the user actively configures something else for a qube, its
IP addresses is based on its qid/dispid (a number from 0 to 10000),
and the MAC addresses is the same for all qubes.
[6] When starting a disposable qube via qrexec, a malicious qube could
try to time the start in its favor.
The Qubes Security Team
https://www.qubes-os.org/security/
Source: qsb-106-2024.txt
Marek Marczykowski-Górecki’s PGP signature
