CVE-2019-10168

The virConnectBaselineHypervisorCPU() and virConnectCompareHypervisorCPU() libvirt APIs accept an "emulator" argument to specify the program providing emulation for a domain. Since v1.2.19, libvirt will execute that program to probe the domain's capabilities. Read-only clients could specify an arbitrary path for this argument, causing libvirtd to execute a crafted executable with its own privileges.

• This vulnerability requires access to the libvirt socket, normally in /var/run/libvirt/libvirt_sock_ro. Typically in hypervisor environments, local user accounts are not supported so no untrusted users should be able to access this socket.
• Red Hat Gluster Storage 3 is not affected by this vulnerability as libvirtd daemon is not shipped in Gluster.

The CVSS score(s) listed for this vulnerability do not reflect the associated product's status, and are included for informational purposes to better understand the severity of this vulnerability.

The Unix permissions of libvirt's read-only socket can be made more restrictive than the default (0777) by editing /etc/libvirt/libvirtd.conf. The settings unix_sock_group = libvirt and unix_sock_ro_perms = 0770 will restrict access to only members of libvirt, who already have management access to virtual machines.