yahoo-eng-team team mailing list archive

[OpenStack Infra <1548450@xxxxxxxxxxxxxxxxxx>]

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 <lyarwood@xxxxxxxxxx>
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