Reviewed: https://review.openstack.org/289957 Committed: https://git.openstack.org/cgit/openstack/nova/commit/?id=116b1210ab772c55d1ed1f715687d83877c92701 Submitter: Jenkins Branch: master
commit 116b1210ab772c55d1ed1f715687d83877c92701 Author: Lee Yarwood <[email protected]> Date: Wed Feb 24 11:23:22 2016 +0000 libvirt: Always copy or recreate disk.info during a migration The disk.info file contains the path and format of any image, config or ephermal disk associated with an instance. When using RAW images and migrating an instance this file should always be copied or recreated. This avoids the Raw imagebackend reinspecting the format of these disks when spawning the instance on the destination host. By not copying or recreating this disk.info file, a malicious image written to an instance disk on the source host will cause Nova to reinspect and record a different format for the disk on the destination. This format then being used incorrectly when finally spawning the instance on the destination. SecurityImpact Closes-bug: #1548450 Change-Id: Idfc16f54049aaeab31ac1c1d8d79a129acc9fb87 ** 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/1548450 Title: [OSSA 2016-007] Host data leak during resize/migrate for raw-backed instances (CVE-2016-2140) Status in OpenStack Compute (nova): Fix Released Status in OpenStack Security Advisory: Fix Committed Bug description: First, a caveat. This report is from code inspection only. I haven't attempted to replicate it, and I have no immediate plans to. It's possible it doesn't exist due to an interaction which isn't immediately obvious. When resizing an instance using the libvirt driver, we run LibvirtDriver.migrate_disk_and_power_off on the source host. If there is no shared storage, data is copied. Specifically, there's a loop in that function which loops over disk info: for info in disk_info: # assume inst_base == dirname(info['path']) ... copy the disk Note that this doesn't copy disk.info, because it's not a disk. I have actually confirmed this whilst investigating another bug. The problem with this is that disk.info contains file format information, which means that when the instance starts up again, the format of all its disks are re-inspected. This is the bug. It means that a malicious user can write data to an ephemeral or root disk which fakes a qcow2 header, and on re-inspection it will be detected as qcow2 and data from a user-specified backing file will be served. I am moderately confident that this is a real bug. Unlike the previous file format bug I reported, though, this bug would be mitigated by the fact that the user would have to access the disk via libvirt/qemu. Assuming they haven't disabled SELinux (nobody does that, right?) this severely limits the data which can be accessed, possibly to the point that it isn't worth exploiting. I also believe it would only be exploitable on deployments using raw storage, which I believe isn't common. Given that I don't think it's all that serious in practise, I'm not going to work on this immediately as I don't have the time. If it's still around when I'm less busy I'll pick it up. To manage notifications about this bug go to: https://bugs.launchpad.net/nova/+bug/1548450/+subscriptions -- Mailing list: https://launchpad.net/~yahoo-eng-team Post to : [email protected] Unsubscribe : https://launchpad.net/~yahoo-eng-team More help : https://help.launchpad.net/ListHelp
