Bugzilla – Bug 829068
VUL-0: CVE-2013-2096: openstack-nova: qcow2 virtual image size denial of serviec
Last modified: 2013-08-06 12:35:14 UTC
is public, via CVE mitre org CVE-2013-2096 OpenStack Compute (Nova) Folsom, Grizzly, and Havana does not verify the virtual size of a QCOW2 image allows local users to cause a denial of service (host file system disk consumption) by creating an image with a large virtual size that does not contain a large amount of data. MLIST:[openstack-announce] 20130516 [OSSA 2013-012] Nova fails to verify image virtual size (CVE-2013-2096) URL:http://lists.openstack.org/pipermail/openstack-announce/2013-May/000102.html CONFIRM:https://review.openstack.org/#/c/28717/ CONFIRM:https://review.openstack.org/#/c/28901/ CONFIRM:https://review.openstack.org/#/c/29192/ UBUNTU:USN-1831-1 URL:http://www.ubuntu.com/usn/USN-1831-1 BID:59924 URL:http://www.securityfocus.com/bid/59924
It most likely affects essex too... Sascha, can you push an update for this?
bugbot adjusting priority
Backported the Folsom upstream fix to Essex, currently in Devel:Cloud:1.0:OpenStack (our staging project). I'll push the update afterwards.
The SWAMPID for this issue is 53579. This issue was rated as moderate. Please submit fixed packages until 2013-07-29. When done, please reassign the bug to security-team@suse.de. Patchinfo will be handled by security team.
sr#27714
during my maintenance QA testing I found that the patch is incomplete. I did perl -e 'for(0..5000){print "x" x (1024*1024)}' > img qemu-img convert -c -O qcow2 img img.qcow2 to create a compressed qcow2 file with a size of 5 GB and created a new flavor that allowed 4GB rootfs max. Then I launched an instance with that flavor and image. This created two 5GB cache files on the compute node under /var/lib/nova/instances/_base/ and only after this it refused to run the instance because of the size restriction. Uploading the same image under a different name and launching another VM with that 'new' image, caused another two cache files to be created and disk space to be exhausted. apart from that, we ship with the m1.tiny flavor with a maximum disk size of 0 and as I read the patch and review, this is exempted from the limit so we should document that people would need to delete that flavor to avoid this DoS attack
filed this new finding upstream https://bugs.launchpad.net/nova/+bug/1206081
Update released for: openstack-nova, openstack-nova-api, openstack-nova-cert, openstack-nova-compute, openstack-nova-network, openstack-nova-objectstore, openstack-nova-scheduler, openstack-nova-test, openstack-nova-vncproxy, openstack-nova-volume, python-nova Products: SUSE-CLOUD 1.0 (x86_64)
I think this can be closed. Fixed RPMs should be there. Freel free to reopen if there's anything left.