Libvirt Security Notice: LSN-2014-0006

virDomainBlockRebase probes file formats in spite of explicit raw request

Lifecycle

Credits

Description

When virDomainBlockRebase gained the VIR_DOMAIN_BLOCK_REBASE_COPY flag, it was documented that libvirt might probe the format of the destination file under certain circumstances; but since file format probing is inherently unsafe for raw images (see CVE-2010-2237), the API also included the VIR_DOMAIN_BLOCK_REBASE_COPY_RAW flag as a safeguard to avoid the probe, in addition to the normal safeguards of /etc/libvirt/qemu.conf being able to forbid all probes. However, if a user has configured to allow probes, then two separate bugs in the implementation create situations where even though the user explicitly requested a raw destination, libvirt can end up probing the file format of the destination after the time that virDomainBlockAbort is used to pivot to that destination. The first bug was introduced in v1.0.0, the same release as the initial support for block copy: if the user requests the raw flag but lets libvirt create the destination, then the destination file will be raw but libvirt fails to record the fact. The second bug was introduced in libvirt v1.2.1 as part of a fix for CVE-2013-6458 (and therefore very likely to be backported to most builds that include block copy support): if the user requests the raw flag and reuses an existing destination file, but then later makes a second attempt to do a block copy while the first copy is still underway, then libvirt will forget that the destination is raw. In either scenario, once libvirt has lost track that the destination is raw, it will probe for the file format after a pivot. Note that although the block copy API was not implemented upstream until v1.0.0, it can be backported to any version that supports virDomainBlockRebase (as old as v0.9.8), so downstream versions with a lower version number may also suffer from these bugs.

Impact

A malicious guest can store what looks like a different file format in the header of its disk image, in the hopes that the host will use block copy to relocate the storage for the guest disk into a raw file. If the host enables format probing, and either bug triggers, then the guest will be serviced by a raw destination after a block copy pivot, and libvirt may deduce the wrong file format in spite of the API being used correctly to copy to a raw destination. Once libvirt probes an incorrect format, it may end up incorrectly labelling host files, granting the guest access to a mislabeled host file, or otherwise violating sVirt protections. However, for either bug to actually happen, the host must set allow_disk_format_probing=1 in /etc/libvirt/qemu.conf; this setting defaults to 0 with a lengthy comment warning of other possible security problems if it is set to 1 without properly specifying formats everywhere. Since any host that sticks with the default configuration of disallowing probes is immune, this vulnerability was not assigned a CVE. Furthermore, block copy as implemented in the affected versions of libvirt is only possible on transient domains, and most known users of block copy only perform shallow copies (where the destination is qcow2 rather than raw), which is also immune to incorrect probe results.

Workaround

The guest cannot trigger the host to misbehave if the host leaves /etc/libvirt/qemu.conf with its default setting of allow_disk_format_probing=0. Furthermore, even if probing is allowed, a host that never performs a block copy to a raw destination file (whether pre-existing, or created by libvirt) will not be impacted. Finally, even if block copy occurs where libvirt forgets that the destination is raw, the worst effects of acting on probed information occur when booting a guest, so it is sufficient to edit the domain XML before each start of a guest, and re-add any lost <driver format='raw'/> element back to any disk that was previously copied to a raw destination, to ensure that libvirt does not probe the image and perform incorrect actions based on the probe. The newer virDomainBlockCopy API is immune to the problem.

Affected product: libvirt

Alternative formats: [xml] [text]