yahoo-eng-team team mailing list archive

[Sean Dague <sean@xxxxxxxxx>]

** Changed in: nova/liberty
       Status: Fix Committed => 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 Compute (nova) kilo series:
  Fix Released
Status in OpenStack Compute (nova) liberty series:
  Fix Released
Status in OpenStack Security Advisory:
  Fix Released

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