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.
OK. So I'm almost 100% certain that this is a valid attack at this point, but still have not tested. See if you can tell me why the following *wouldn't* work. to/another/ instances/ i-0000002/ disk' or possibly /etc/shadow. likely/ other/users/ instance/ disk)
Below:
* FILE is a path to something that you should not be able to read. '/dev/sda' or '/path/
* $KERNEL is probably a normal kernel possibly a distro built one
* $RAMDISK is a fully functional OS in a ramdisk (with an ssh server to reach it), but you probably don't even need this if you have vnc console access (to interactively 'fix' possibly failed initramfs boot).
* FILE=/dev/sda (or /path/to/
So, to attack:
* qemu-img create -f qcow2 -b $FILE my-attack.img
* cloud-publish-image --kernel-file $KERNEL --ramdisk-file $RAMDISK x86_64 $FILE my-attack-bucket
* euca-run-instances ami-abcdefg
* ssh to new (initramfs based rootfs), and start reading from $FILE