| 2011-09-18 16:31:02 |
Scott Moser |
bug |
|
|
added bug |
| 2011-09-18 16:31:22 |
Scott Moser |
bug |
|
|
added subscriber Ubuntu Security Team |
| 2011-09-18 16:31:32 |
Scott Moser |
bug |
|
|
added subscriber Dave Walker |
| 2011-09-18 16:35:33 |
Scott Moser |
description |
I've only just thought of this issue, and have not investigated further. There may be a security issue in enabling qcow images that could be exploited like this:
* user creates an image with 'qemu-img create -f qcow2 -b <FILE> mytest.img' . Here, FILE could be anything thing (/etc/shadow, /var/lib/libvirt/qemu/isntance-0000030/disk.local).
* user uploads images: cloud-publish-image x86_64 mytest.img mybucket
* user runs instance
Things that may make this less severe:
* i believe in ubuntu that the user libvirt-qemu user is used to run kvm, so that the file access might be limited to what that user can access.
* in ubuntu apparmor profiles for libvirt *may* improve this, although I don't know that they were written to protect against this.
* the instance wont' actually boot. (However, I think it may be possible using block-device-mapping to attach a bootable snapshot to this instance that *would* boot, and then access the root disk that way).
I believe this could be fixed by simply refusing to run a qcow2 formated image (or any disk image) whose original image contained a backing store reference . Ie, if 'qemu-img info <disk>' showed a 'backing file:' entry. |
I've only just thought of this issue, and have not investigated further. There may be a security issue in enabling qcow images that could be exploited like this:
* user creates an image with 'qemu-img create -f qcow2 -b <FILE> mytest.img' . Here, FILE could be anything thing (/etc/shadow, /var/lib/libvirt/qemu/isntance-0000030/disk.local).
* user uploads images: cloud-publish-image x86_64 mytest.img mybucket
* user runs instance
Things that may make this less severe:
* i believe in ubuntu that the user libvirt-qemu user is used to run kvm, so that the file access might be limited to what that user can access.
* in ubuntu apparmor profiles for libvirt *may* improve this, although I don't know that they were written to protect against this.
* the instance wont' actually boot. (However, I think it may be possible using block-device-mapping to attach a bootable snapshot or volume to this instance that *would* boot, and then access the root disk that way).
I believe this could be fixed by simply refusing to run a qcow2 formated image (or any disk image) whose original image contained a backing store reference . Ie, if 'qemu-img info <disk>' showed a 'backing file:' entry. |
|
| 2011-09-19 12:32:46 |
Scott Moser |
bug |
|
|
added subscriber Soren Hansen |
| 2011-09-19 14:30:10 |
Scott Moser |
attachment added |
|
example of how to create a 2 level qcow disk https://bugs.launchpad.net/nova/+bug/853330/+attachment/2426606/+files/go-2level-exploit |
|
| 2011-09-19 15:17:54 |
Scott Moser |
nova: status |
New |
In Progress |
|
| 2011-09-19 15:17:54 |
Scott Moser |
nova: assignee |
|
Scott Moser (smoser) |
|
| 2011-09-19 15:33:41 |
Soren Hansen |
nova: importance |
Undecided |
High |
|
| 2011-09-19 16:41:31 |
Scott Moser |
bug |
|
|
added subscriber Chuck Short |
| 2011-09-19 16:59:10 |
Marc Deslauriers |
cve linked |
|
2011-3147 |
|
| 2011-09-19 17:15:53 |
Scott Moser |
attachment added |
|
proposed patch against trunk https://bugs.launchpad.net/nova/+bug/853330/+attachment/2427234/+files/lp-853330.diff |
|
| 2011-09-19 17:40:16 |
Brian Waldon |
nova: milestone |
|
2011.3 |
|
| 2011-09-19 17:55:56 |
Scott Moser |
description |
I've only just thought of this issue, and have not investigated further. There may be a security issue in enabling qcow images that could be exploited like this:
* user creates an image with 'qemu-img create -f qcow2 -b <FILE> mytest.img' . Here, FILE could be anything thing (/etc/shadow, /var/lib/libvirt/qemu/isntance-0000030/disk.local).
* user uploads images: cloud-publish-image x86_64 mytest.img mybucket
* user runs instance
Things that may make this less severe:
* i believe in ubuntu that the user libvirt-qemu user is used to run kvm, so that the file access might be limited to what that user can access.
* in ubuntu apparmor profiles for libvirt *may* improve this, although I don't know that they were written to protect against this.
* the instance wont' actually boot. (However, I think it may be possible using block-device-mapping to attach a bootable snapshot or volume to this instance that *would* boot, and then access the root disk that way).
I believe this could be fixed by simply refusing to run a qcow2 formated image (or any disk image) whose original image contained a backing store reference . Ie, if 'qemu-img info <disk>' showed a 'backing file:' entry. |
I've only just thought of this issue, and have not investigated further. There may be a security issue in enabling qcow images that could be exploited like this:
* user creates an image with 'qemu-img create -f qcow2 -b <FILE> mytest.img' . Here, FILE could be anything thing (/etc/shadow, /var/lib/libvirt/qemu/isntance-0000030/disk.local).
* user uploads images: cloud-publish-image x86_64 mytest.img mybucket
* user runs instance
Things that may make this less severe:
* i believe in ubuntu that the user libvirt-qemu user is used to run kvm, so that the file access might be limited to what that user can access.
* in ubuntu apparmor profiles for libvirt *may* improve this, although I don't know that they were written to protect against this.
* the instance wont' actually boot. (However, I think it may be possible using block-device-mapping to attach a bootable snapshot or volume to this instance that *would* boot, and then access the root disk that way).
* this only affects installs where 'use_cow_images' is True. If it is false, then libvirt wills specify to kvm that the disk is 'raw' and kvm will not invoke the qemu code path which would read the backing store.
I believe this could be fixed by simply refusing to run a qcow2 formated image (or any disk image) whose original image contained a backing store reference . Ie, if 'qemu-img info <disk>' showed a 'backing file:' entry. |
|
| 2011-09-19 18:13:37 |
Brian Waldon |
bug |
|
|
added subscriber Jay Pipes |
| 2011-09-19 21:15:36 |
Scott Moser |
attachment added |
|
revised patch https://bugs.launchpad.net/nova/+bug/853330/+attachment/2428444/+files/revised-patch.diff |
|
| 2011-09-20 01:51:47 |
Scott Moser |
attachment added |
|
diff against trunk at revno 1594 https://bugs.launchpad.net/nova/+bug/853330/+attachment/2429120/+files/lp853330-trunk.diff |
|
| 2011-09-20 01:52:29 |
Scott Moser |
attachment added |
|
diff against milestone-proposed at 1184 https://bugs.launchpad.net/nova/+bug/853330/+attachment/2429121/+files/lp853330-milestone-proposed.diff |
|
| 2011-09-20 01:52:47 |
Scott Moser |
attachment removed |
proposed patch against trunk https://bugs.launchpad.net/nova/+bug/853330/+attachment/2427234/+files/lp-853330.diff |
|
|
| 2011-09-20 01:52:58 |
Scott Moser |
attachment removed |
revised patch https://bugs.launchpad.net/nova/+bug/853330/+attachment/2428444/+files/revised-patch.diff |
|
|
| 2011-09-20 07:29:24 |
Launchpad Janitor |
branch linked |
|
lp:~smoser/nova/lp853330 |
|
| 2011-09-20 07:30:29 |
Launchpad Janitor |
branch linked |
|
lp:~smoser/nova/milestone-proposed.lp853330 |
|
| 2011-09-20 10:12:09 |
OpenStack Infra |
nova: status |
In Progress |
Fix Committed |
|
| 2011-09-26 08:42:17 |
Thierry Carrez |
visibility |
private |
public |
|
| 2011-09-26 08:42:38 |
Thierry Carrez |
nova: status |
Fix Committed |
Fix Released |
|
| 2011-10-04 11:38:29 |
James Troup |
bug |
|
|
added subscriber The Canonical Sysadmins |
