REDHAT-BUG-2531811: Medium severity libvirt libvirt vulnerability
A symlink-following flaw was found in libvirt's qemuTPMEmulatorPrepareHost() function (src/qemu/qemutpm.c). The function uses a path-based chown() to set ownership of the swtpm logfile without verifying that the path is not a symbolic link. Since the log directory is writable by the swtpm user, a local attacker with access to the swtpm account can replace the logfile with a symlink pointing to an arbitrary file. When libvirtd (running as root) starts a QEMU domain with an emulated TPM, it follows the symlink and transfers ownership of the target file to swtpm:swtpm, allowing the attacker to then modify that file.
The upstream fix replaces the path-based chown() with open(ONOFOLLOW) + fchown() on the file descriptor.
External reference: https://gitlab.com/libvirt/libvirt/-/workitems/909
Affected Software
Remediation
Recommended actions to resolve this vulnerability, in priority order.
- Upgrade
Upgrade
libvirtto a version that resolves this vulnerability.Patch gitlab.com/libvirt/libvirt/-/work_items/909 - Compensating control
Ensure the swtpm user cannot write to the libvirt/QEMU TPM emulator log directory (or make the logfile path non-writable for swtpm) to prevent swtpm from replacing the logfile with a symlink.
Event History
Frequently Asked Questions
Who can exploit this issue?
A local attacker needs access to the swtpm account and the ability to write in the swtpm log directory. Remote access alone is not described as sufficient.
What event triggers the vulnerable ownership change?
The issue is triggered when libvirtd, running as root, starts a QEMU domain configured with an emulated TPM. The attacker must replace the expected swtpm logfile with a symbolic link before that operation.
What is the impact of successful exploitation?
libvirtd can change ownership of the symlink target to swtpm:swtpm. The attacker can then modify that target file using the swtpm account.
What mitigation is indicated if an update cannot be applied immediately?
Restrict access to the swtpm account and prevent untrusted users from writing to the swtpm log directory. Avoid starting QEMU domains with emulated TPMs where those controls cannot be assured.
How can this behavior be remediated in the code?
The upstream fix opens the logfile with O_NOFOLLOW and performs fchown() on the resulting file descriptor, rather than using path-based chown().