libvirt privilege escalation vulnerabilities

Overview

A number of related vulnerabilities in the libvirt management API were recently discovered and fixed by the libvirt maintainers. These vulnerabilities expose unintended functionality to API clients with read-only permissions that could be used by the client to perform operations outside their normal sphere of permissions. The most severe vulnerability, with default configuration, could allow a read-only local API user to gain privilege escalation to root on Red Hat Enterprise Linux 8. The issues have been assigned multiple CVEs, all considered Important severity: CVE-2019-10161 CVE-2019-10166 CVE-2019-10167 CVE-2019-10168

Background

Libvirtd is the daemon component of libvirt. It is responsible for managing the configuration and status of virtual machines and exposes an API over a Unix domain socket for clients such as virsh to manage those VMs.

Libvirt clients can connect in “privileged” read/write mode, or in “unprivileged” read-only mode. The read-only mode is supposed to only allow queries: a read-only client can interrogate libvirt about the VMs it manages, but to change configuration or state requires a read/write connection.

As the libvirt API has evolved over time, the line between “privileged” and “unprivileged” operations became less clear. API calls that were originally exposed read-only, gained more capabilities that made them more powerful, but introduced security risks that were not obvious at the time.

Impact

This vulnerability is normally exposed to local users on the host where libvirtd is running (AV:L). Thus, multi-user Red Hat Enterprise Linux systems that host virtual machines are at the greatest risk.

Hypervisor hosts such as Red Hat Virtualization Hypervisor typically do not support local users other than the administrator, so the impact in these environments is less severe.

Administrative changes made to /etc/libvirt/libvirtd.conf may affect your level of exposure:

• If you have enabled the setting listen_tcp, network users that can reach the libvirt port may be able to conduct an attack.
• If access to libvirt is restricted by changing unix_sock_ro_perms to something more restrictive than 0777, only those users able to connect() to the socket will be able to attack libvirtd. For example, the following allows only members of the libvirt group:

    unix_sock_group = "libvirt"
    unix_sock_ro_perms = "0770"

The potential impact an attack could achieve includes:

• Testing for the existence of files on the host as root. Libvirtd can be given an arbitrary path to read a saved state file, which it will attempt to read (CVE-2019-10161).
• Denial of service. By choosing particular paths in /dev or /proc with CVE-2019-10161, libvirtd could lock or interfere with other processes on the host.
• Privilege escalation to the “qemu” user. Libvirtd can be convinced to execute an attacker-specified binary, which will be invoked under the qemu user id. This could permit an attacker to start, stop, manipulate, or compromise other virtual machines managed by livbirt (all CVEs).
• Privilege escalation to “root” in Red Hat Enterprise Linux 8. In this version of libvirtd, the binary is also executed with CAP_DAC_OVERRIDE, allowing it to read and write root-owned files.

The privilege escalation attacks are not possible on Red Hat Enterprise Linux 6, as that version of libvirt does not probe emulator capabilities by executing the binary. Only denial of service and testing for the existence of root-owned files are possible there.

Red Hat Enterprise Linux 7 is additionally vulnerable to privilege escalation attacks, but only to the “qemu” userid.

On Red Hat Enterprise Linux 8, full root compromise is possible due to use of the CAP_DAC_OVERRIDE capability flag.

Diagnostics

If your system has a libvirtd process running as root, and has not had the below updates applied, it is vulnerable. On Red Hat Enterprise Linux, if you have the libvirt-daemon package installed, this process is started by default to enable the qemu:///system connection. You can check with any of the following commands:

    $ systemctl status libvirtd
    $ virsh -r -c qemu:///system list
    $ ls -l /var/run/libvirt/libvirt-sock-ro

Mitigation

Red Hat recommends updating your libvirt packages according to the table located in the affected products section.

Alternatively, access to the libvirt read-only socket can be restricted to root only, or to a trusted user group. This will impact monitoring of your virtual machines through the read-only socket, but management through the privileged socket will continue to work. To restrict access, edit the file /etc/libvirt/libvirtd.conf:

Affected Products