See how libvirt compares to other vendors in security performance
Daniel Berrange discovered that libvirt fails to check whether connection to libvirtd is in read-only or read-write mode, possibly allowing non-privileged users with access to the host machine to perform certain actions that should be restricted to administrative users only.
The following methods in libvirt.c are missing a check against the read-only connection flag:
virDomainMigrate virDomainMigratePrepare virDomainMigratePerform virDomainMigrateFinish virDomainMigratePrepare2 virDomainMigrateFinish2 virDomainBlockPeek virDomainMemoryPeek virDomainSetAutostart virNetworkSetAutostart virConnectFindStoragePoolSources virStoragePoolSetAutostart
In recent versions, libvirt uses PolicyKit to authorize connections from users. Default policy allows any local user to connect in the read-only mode.
Older versions of libvirt, or version not compiled with PolicyKit or with PolicyKit authorization disabled, default to allow read-only connections to all local users.
Thus out of the box unprivileged local users may be able to migrate VMs, set or unset the autostart flag for domains, networks & storage pools, and access privileged data in the VM memory, or disks.
All TCP remote connections are read-write, and fully authenticated, thus not impacted.
A symlink-following vulnerability was found in libvirt's virFileChownFiles() function in src/util/virfile.c. This function is called from src/qemu/qemutpm.c to change ownership of the swtpm state directory when starting a QEMU domain.
The function used stat() (via virFileIsRegular()) and chown(), both of which follow symlinks. A process running as the confined swtpm user (tss) can plant a symlink inside the swtpm state directory pointing to an arbitrary file. When the root-level libvirt daemon starts the next domain, it calls virFileChownFiles() which follows the symlink and chowns the target file to the tss user. This allows escalation from the swtpm sandbox to root-level file ownership control.
The fix replaces stat()/chown() with lstat()/lchown() to avoid following symlinks on the final path component.
Upstream fix: https://gitlab.com/libvirt/libvirt/-/commit/801160fd414ca2cc402bc01ead09b7ed4c3b8f5b
A vulnerability was found in libvirt >= 4.1.0 in the virtlockd-admin.socket and virtlogd-admin.socket systemd units. A missing SocketMode configuration parameter allows any user on the host to connect using virtlockd-admin-sock or virtlogd-admin-sock and perform administrative tasks against the virtlockd and virtlogd daemons.
Daniel P. Berrange reported:
"As non-root, simply run:
# virsh -c qemu:///system --readonly iface-list --inactive
The libvirtd daemon will crash with one of a number of different stack traces, for example:
Error in /home/berrange/src/virt/libvirt/daemon/.libs/lt-libvirtd': invalid fastbin entry (free): 0x00007f03fc02a1b0 ======= Backtrace: ========= /lib64/libc.so.6(+0x3cd5e7cef8)[0x7f0425cf7ef8] /home/berrange/src/virt/libvirt/src/.libs/libvirt.so.0(virFree+0x2e)[0x7f04293fd79e] /home/berrange/src/virt/libvirt/src/.libs/libvirt.so.0(virLogVMessage+0x37d)[0x7f042942384d] /home/berrange/src/virt/libvirt/src/.libs/libvirt.so.0(virLogMessage+0x97)[0x7f0429423b27] /home/berrange/src/virt/libvirt/src/.libs/libvirt.so.0(virObjectUnref+0x65)[0x7f04294324d5] /home/berrange/src/virt/libvirt/src/.libs/libvirt.so.0(virIdentitySetCurrent+0x35)[0x7f042941ae25] /home/berrange/src/virt/libvirt/src/.libs/libvirt.so.0(virNetServerProgramDispatch+0x392)[0x7f0429539be2] /home/berrange/src/virt/libvirt/src/.libs/libvirt.so.0(+0x195d68)[0x7f0429533d68] /home/berrange/src/virt/libvirt/src/.libs/libvirt.so.0(+0xa62e5)[0x7f04294442e5] /home/berrange/src/virt/libvirt/src/.libs/libvirt.so.0(+0xa594e)[0x7f042944394e] /lib64/libpthread.so.0(+0x3cd6207c53)[0x7f0426449c53] /lib64/libc.so.6(clone+0x6d)[0x7f0425d6fecd]
Looking at the code, we have a double-free of the 'struct netcfif' object when any of the filtering flags are set. Hence this only happens if you pass '--inactive' to virsh."
Upstream fix:
http://libvirt.org/git/?p=libvirt.git;a=commit;h=244e0b8cf15ca2ef48d82058e728656e6c4bad11
Acknowledgements:
This issue was discovered by Daniel P. Berrange of Red Hat.
Commit 632180d1 introduced memory corruption in xenDaemonListDefinedDomains() by starting to populate the names array at index -1, causing all sorts of havoc in libvirtd such as aborts like the following
Error in /usr/sbin/libvirtd': double free or corruption (out): 0x00007fffe00ccf20
The xenDaemonListDefinedDomains() function is reached by the virConnectListDefinedDomains() public API, which can be used on read-only connections.
Introduced in: libvirt v1.1.1
Introduced by: http://libvirt.org/git/?p=libvirt.git;a=commit;h=632180d1
Fixed by: http://libvirt.org/git/?p=libvirt.git;a=commit;h=0e671a16
A flaw was found in libvirt where libvirtd could crash due to how XML was parsed [1]. With the introduction of ACL permissions in libvirt 1.1.0, this flaw could be manipulated to allow a remote user with connect:read privileges to elevate them to the more permissive domain:write privilege.
This vulnerability was introduced in libvirt 1.1.0.
[1] https://bugzilla.redhat.com/showbug.cgi?id=1012196;
The qemuDomainGetBlockIoTune function in qemu/qemudriver.c in libvirt before 1.2.9, when a disk has been hot-plugged or removed from the live image, allows remote attackers to cause a denial of service (crash) or read sensitive heap information via a crafted blkiotune query, which triggers an out-of-bounds read.
A flaw was discovered in libvirt in the XML file processing. More specifically, the parsing of user provided XML files was performed before the ACL checks (https://libvirt.org/acl.html). A malicious user with limited permissions could exploit this flaw by submitting a specially crafted XML file, causing libvirt to allocate too much memory on the host. The excessive memory consumption could lead to a libvirt process crash on the host, resulting in a denial-of-service condition.
Upstream issue: https://gitlab.com/libvirt/libvirt/-/issues/825
Patch: https://lists.libvirt.org/archives/list/devel@lists.libvirt.org/thread/LTGHU3S4JEMCF5KJNJGWWZ7F2CS6L5SG/
A flaw was found in libvirt. External inactive snapshots for shut-down VMs are incorrectly created as world-readable, making it possible for unprivileged users to inspect the guest OS contents. This results in an information disclosure vulnerability.
A file permission vulnerability was found in libvirt's storage volume clone/convert path in src/storage/storageutil.c. The virStorageBackendCreateExecCommand() function ran qemu-img with umask 0 on non-NETFS local storage paths, causing newly created volume images to be world-readable (mode 0644) during the copy operation. libvirt only tightened the file permissions via chmod() after qemu-img completed, creating a window where the full guest disk contents could be read by any local user.
This is the same class of issue as CVE-2025-13193. A local attacker could exploit this race window to read sensitive guest disk contents, resulting in information disclosure.
The fix moves the virCommandSetUmask() call to apply unconditionally to all code paths, ensuring qemu-img creates files with restrictive permissions from the outset.
Upstream fix: https://gitlab.com/libvirt/libvirt/-/commit/69335a484768d550854da1133d5490074695e825
It was reported that the libvirt daemon using RBD leaks ceph key/id in the process list:
As a non-privileged user you can run ps -ef | grep libvirt and see the below output. In this you can see libvirt using the ceph key as part of the command to run the VM. In particular this section
~~~ -drive file=rbd:mgmt/os-network:id=libvirt:key=AQA/H4dUwLYnORAAhWv2E+67eN72ue3rrl2klg==:authsupported=cephx none,if=none,id=drive-virtio-disk0,format=raw,cache=writeback ~~~
With the 'id' and 'key' values, any user can perform any operations on the cluster which that key provides. Typically, that would be the ability to create/delete RBDs within the cinder pool.
Full output: ~~~ qemu 13924 1 33 Dec10 ? 2-23:31:12 /usr/libexec/qemu-kvm -S -M rhel6.1.0 -enable-kvm -m 8000 -smp 8,sockets=8,cores=1,threads=1 -name os-network -uuid f0ede7e8-c15a-4813-900e-971988d494c1 -nodefconfig -nodefaults -chardev socket,id=charmonitor,path=/var/lib/libvirt/qemu/os-network.monitor,server,nowait -mon chardev=charmonitor,id=monitor,mode=control -rtc base=utc -no-shutdown -device piix3-usb-uhci,id=usb,bus=pci.0,addr=0x1.0x2 -drive file=rbd:mgmt/os-network:id=libvirt:key=AQA/H4dUwLYnORAAhWv2E+67eN72ue3rrl2klg==:authsupported=cephx none,if=none,id=drive-virtio-disk0,format=raw,cache=writeback -device virtio-blk-pci,scsi=off,bus=pci.0,addr=0x9,drive=drive-virtio-disk0,id=virtio-disk0,bootindex=1 -netdev tap,fd=21,id=hostnet0,vhost=on,vhostfd=27 -device virtio-net-pci,netdev=hostnet0,id=net0,mac=52:54:00:64:92:b6,bus=pci.0,addr=0x3 -netdev tap,fd=28,id=hostnet1,vhost=on,vhostfd=29 -device virtio-net-pci,netdev=hostnet1,id=net1,mac=52:54:00:f7:50:e2,bus=pci.0,addr=0x4 -netdev tap,fd=30,id=hostnet2,vhost=on,vhostfd=31 -device virtio-net-pci,netdev=hostnet2,id=net2,mac=52:54:00:14:3b:33,bus=pci.0,addr=0x5 -netdev tap,fd=32,id=hostnet3,vhost=on,vhostfd=33 -device virtio-net-pci,netdev=hostnet3,id=net3,mac=52:54:00:fd:86:aa,bus=pci.0,addr=0x6 -chardev pty,id=charserial0 -device isa-serial,chardev=charserial0,id=serial0 -device usb-tablet,id=input0 -vnc 127.0.0.1:5 -vga cirrus -device intel-hda,id=sound0,bus=pci.0,addr=0x8 -device hda-duplex,id=sound0-codec0,bus=sound0.0,cad=0 -device virtio-balloon-pci,id=balloon0,bus=pci.0,addr=0x7 ~~~
The virDomainListPopulate function in conf/domainconf.c in libvirt before 1.2.9 does not clean up the lock on the list of domains, which allows remote attackers to cause a denial of service (deadlock) via a NULL value in the second parameter in the virConnectListAllDomains API command.
A buffer overflow flaw was found in libvirtproxy. libvirtproxy is set to run as a setuid root by default, so in theory this could allow for a local user to become root.
Normally the stack protector would prevent this from being an issue, but it seems that with gcc optimizations, the function in question is being inlined into main(), preventing the stack protector from catching this.
The original report can be found here: https://www.redhat.com/archives/libvir-list/2009-January/msg00699.html
The patch is here: http://git.et.redhat.com/?p=libvirt.git;a=commitdiff;h=2bb0657e28
It was found that libvirt did not honour the user defined main disk format in guest XML when looking up disk backing stores in the security drivers. This could be possibly exploited by priviledged guest user to access arbitrary files on the host.
It was found that libvirt did not explicitly set the user defined backing store format when creating new image. This results in images being created with an potentialy insecure configuration, preventing applications from opening backing stores without resorting to probing. A priviledged guest user could use this flaw to access arbitrary files on the host.
It was found that libvirt did not extract the defined disk backing store format when recursing into disk image backing stores in the security drivers. This could be possibly exploited by priviledged guest user to access arbitrary files on the host.
A flaw was found in the RPC library APIs of libvirt. The RPC server de-serialization code allocates memory for arrays before the non-negative length check is performed by the C API entry points. Passing a negative length to the gnew0 function results in a crash due to the negative length being treated as a huge positive number. A local unprivileged user could use this flaw to perform a denial of service attack by causing the libvirt daemon to crash.
A race condition leading to a stack use-after-free bug was found in libvirt. Due to a bad assumption in the virNetClientIOEventLoop() method, the data pointer to a stack-allocated virNetClientIOEventData structure ended up being used in virNetClientIOEventFD callback while the data pointer's stack frame was concurrently being "freed" when returning from virNetClientIOEventLoop().
Quoting libvirt maintainer Daniel P. Berrangé: The 'virtproxyd' daemon can be used to trigger requests which could potentially exercise the bug. If libvirt is configured with fine grained access control, this could in theory let a user escape their otherwise limited access. A local unprivileged user can access virtproxyd without authenticating. Remote users would need to authenticate before they could exercise it.
A refactor of the code fetching the list of interfaces for multiple APIs introduced a corner case on platforms where allocating 0 bytes of memory results in a NULL pointer.
This corner case would lead to a NULL-pointer dereference and subsequent crash of virtinterfaced if virConnectListInterfaces() is called requesting 0 networks to be filled.
The bug was introduced in libvirt-10.4.0 and reproduces only on platforms where allocation of 0-length memory returns NULL instead of a valid pointer.
Upstream fix: https://gitlab.com/libvirt/libvirt/-/commit/8dfb12cb77996519901b8d52c754ab564ebd10e8
A flaw was discovered in libvirt in the XML file processing. More specifically, the parsing of user provided XML files was performed before the ACL checks (https://libvirt.org/acl.html). A malicious user with limited permissions could exploit this flaw by submitting a specially crafted XML file, causing libvirt to allocate too much memory on the host. The excessive memory consumption could lead to a libvirt process crash on the host, resulting in a denial-of-service condition.
Upstream issue: https://gitlab.com/libvirt/libvirt/-/issues/825
Patch: https://lists.libvirt.org/archives/list/devel@lists.libvirt.org/thread/LTGHU3S4JEMCF5KJNJGWWZ7F2CS6L5SG/
External inactive snapshots for shut-down VMs are incorrectly created as world-readable, making it possible for unprivileged users to inspect the guest OS contents. This results in an information disclosure vulnerability.
Debian bug: https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=1120119
Upstream patch: https://gitlab.com/libvirt/libvirt/-/commit/a379327d8abcde8ac8d3e16fe5e4ba6f790d767a
An invalid free flaw in the libxl driver in libvirt resulted in libvirt crashing if "virsh numatune" was run on an inactive domain. It may be possible, but unlikely, for an attacker to leverage this flaw for arbitrary code execution.
This issue affects the version of libvirt in Fedora 20. It does not affect the versions of libvirt in Red Hat Enterprise Linux 5 and 6 as those versions do not use libxl.
It was reported that the libvirt daemon using RBD leaks ceph key/id in the process list:
As a non-privileged user you can run ps -ef | grep libvirt and see the below output. In this you can see libvirt using the ceph key as part of the command to run the VM. In particular this section
~~~ -drive file=rbd:mgmt/os-network:id=libvirt:key=AQA/H4dUwLYnORAAhWv2E+67eN72ue3rrl2klg==:authsupported=cephx none,if=none,id=drive-virtio-disk0,format=raw,cache=writeback ~~~
With the 'id' and 'key' values, any user can perform any operations on the cluster which that key provides. Typically, that would be the ability to create/delete RBDs within the cinder pool.
Full output: ~~~ qemu 13924 1 33 Dec10 ? 2-23:31:12 /usr/libexec/qemu-kvm -S -M rhel6.1.0 -enable-kvm -m 8000 -smp 8,sockets=8,cores=1,threads=1 -name os-network -uuid f0ede7e8-c15a-4813-900e-971988d494c1 -nodefconfig -nodefaults -chardev socket,id=charmonitor,path=/var/lib/libvirt/qemu/os-network.monitor,server,nowait -mon chardev=charmonitor,id=monitor,mode=control -rtc base=utc -no-shutdown -device piix3-usb-uhci,id=usb,bus=pci.0,addr=0x1.0x2 -drive file=rbd:mgmt/os-network:id=libvirt:key=AQA/H4dUwLYnORAAhWv2E+67eN72ue3rrl2klg==:authsupported=cephx none,if=none,id=drive-virtio-disk0,format=raw,cache=writeback -device virtio-blk-pci,scsi=off,bus=pci.0,addr=0x9,drive=drive-virtio-disk0,id=virtio-disk0,bootindex=1 -netdev tap,fd=21,id=hostnet0,vhost=on,vhostfd=27 -device virtio-net-pci,netdev=hostnet0,id=net0,mac=52:54:00:64:92:b6,bus=pci.0,addr=0x3 -netdev tap,fd=28,id=hostnet1,vhost=on,vhostfd=29 -device virtio-net-pci,netdev=hostnet1,id=net1,mac=52:54:00:f7:50:e2,bus=pci.0,addr=0x4 -netdev tap,fd=30,id=hostnet2,vhost=on,vhostfd=31 -device virtio-net-pci,netdev=hostnet2,id=net2,mac=52:54:00:14:3b:33,bus=pci.0,addr=0x5 -netdev tap,fd=32,id=hostnet3,vhost=on,vhostfd=33 -device virtio-net-pci,netdev=hostnet3,id=net3,mac=52:54:00:fd:86:aa,bus=pci.0,addr=0x6 -chardev pty,id=charserial0 -device isa-serial,chardev=charserial0,id=serial0 -device usb-tablet,id=input0 -vnc 127.0.0.1:5 -vga cirrus -device intel-hda,id=sound0,bus=pci.0,addr=0x8 -device hda-duplex,id=sound0-codec0,bus=sound0.0,cad=0 -device virtio-balloon-pci,id=balloon0,bus=pci.0,addr=0x7 ~~~
A vulnerability was found in libvirt, where an incorrect permissions on the UNIX domain socket. A local attacker could use this issue to access libvirt and escalate privileges.
References: https://bugs.mageia.org/27038
Daniel Berrange discovered that libvirt fails to check whether connection to libvirtd is in read-only or read-write mode, possibly allowing non-privileged users with access to the host machine to perform certain actions that should be restricted to administrative users only.
The following methods in libvirt.c are missing a check against the read-only connection flag:
virDomainMigrate virDomainMigratePrepare virDomainMigratePerform virDomainMigrateFinish virDomainMigratePrepare2 virDomainMigrateFinish2 virDomainBlockPeek virDomainMemoryPeek virDomainSetAutostart virNetworkSetAutostart virConnectFindStoragePoolSources virStoragePoolSetAutostart
In recent versions, libvirt uses PolicyKit to authorize connections from users. Default policy allows any local user to connect in the read-only mode.
Older versions of libvirt, or version not compiled with PolicyKit or with PolicyKit authorization disabled, default to allow read-only connections to all local users.
Thus out of the box unprivileged local users may be able to migrate VMs, set or unset the autostart flag for domains, networks & storage pools, and access privileged data in the VM memory, or disks.
All TCP remote connections are read-write, and fully authenticated, thus not impacted.
It was found that libvirt did not extract the defined disk backing store format when recursing into disk image backing stores in the security drivers. This could be possibly exploited by priviledged guest user to access arbitrary files on the host.
It was found that libvirt did not honour the user defined main disk format in guest XML when looking up disk backing stores in the security drivers. This could be possibly exploited by priviledged guest user to access arbitrary files on the host.
A flaw was found in libvirt. The network XML parser accepts XML numeric character references for line breaks ( / ) in DNS TXT record value attributes and SRV record domain/target attributes without sanitization. The network driver writes these values directly into the line-oriented dnsmasq configuration file as txt-record= or srv-host= directives. An embedded newline terminates the intended directive and begins a new one under attacker control (e.g., dhcp-script=/bin/sh -c '<cmd>'), which dnsmasq executes as root when the virtual network is started. Under the default libvirt deployment model, read-write access to the libvirt socket is already root-equivalent, and the <dnsmasq:options> raw namespace already provides a documented mechanism for arbitrary directive injection, making this a hardening issue only. However, under non-default polkit fine-grained access control configurations that grant only network.write and network.start permissions, this could represent a privilege boundary violation.
Jeremy Nickurak reported an issue with how libvirt creates iptables rules when guest systems are setup for masquerading. The iptables rule will be of the following format:
iptables-save -t nat Generated by iptables-save v1.4.7 on Wed Jun 9 14:59:03 2010 nat :PREROUTING ACCEPT [45:5146] :POSTROUTING ACCEPT [889:54117] :OUTPUT ACCEPT [889:54117] -A POSTROUTING -s 192.168.122.0/24 ! -d 192.168.122.0/24 -j MASQUERADE COMMIT Completed on Wed Jun 9 14:59:03 2010
With masquerading, outgoing connections will have their source-port mapped to a NAT-selected port, and the iptables default is for privileged ports to be mapped to privileged (<1024) ports.
This will allow users in guests that have root privileges (in the guest, independent of their privileges on the host), to obtain privileged resources on the host, as well as being able to access other resources by using it. One example is with standard NFS exports now being accessible to the guests, because the guests will appear to be from the same IP as a possibly trusted host.
To illustrate:
regular-user@host-machine:~$ ssh guest-machine Last login: Wed Jun 9 11:33:13 2010 from host-machine regular-user@guest-machine:~$ sudo mount -t nfs -o udp,rw,soft remote-nfs-server:/some-export /mnt/tmp
(get UID of resources on the remote NFS server, and create a user in the guest with that UID> (su to that new UID)
user-with-same-uid@guest-machine:~$ cp -R /mnt/tmp/secret-data /home/mycopy; rm -Rf /mnt/tmp/secret-data
A normal user account would not normally be able to do something like this because they cannot bind to the privileged port, however in this case the NAT rules permits it.
An example modified set of iptables rules that may solve the problem was supplied as well:
/sbin/iptables -t nat -A POSTROUTING -p tcp -o $(IFACE) -j MASQUERADE --to-ports 1024-65535 /sbin/iptables -t nat -A POSTROUTING -p udp -o $(IFACE) -j MASQUERADE --to-ports 1024-65535 /sbin/iptables -t nat -A POSTROUTING -p icmp -o $(IFACE) -j MASQUERADE
The above uses the --to-ports option that forces iptables' masquerading module to only map guest reqursts to non-privileged ports.
Acknowledgements:
Red Hat would like to thank Jeremy Nickurak for reporting this issue.
A flaw was found in libvirt. The network XML parser accepts XML numeric character references for line breaks ( / ) in DNS TXT record value attributes and SRV record domain/target attributes without sanitization. The network driver writes these values directly into the line-oriented dnsmasq configuration file as txt-record= or srv-host= directives. An embedded newline terminates the intended directive and begins a new one under attacker control (e.g., dhcp-script=/bin/sh -c '<cmd>'), which dnsmasq executes as root when the virtual network is started. Under the default libvirt deployment model, read-write access to the libvirt socket is already root-equivalent, and the <dnsmasq:options> raw namespace already provides a documented mechanism for arbitrary directive injection, making this a hardening issue only. However, under non-default polkit fine-grained access control configurations that grant only network.write and network.start permissions, this could represent a privilege boundary violation.