yahoo-eng-team team mailing list archive

[Dave Walker <email@xxxxxxxxxx>]

** Also affects: nova/kilo
   Importance: Undecided
       Status: New

-- 
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/1524274

Title:
  [OSSA 2016-001] Unprivileged api user can access host data using
  instance snapshot (CVE-2015-7548)

Status in OpenStack Compute (nova):
  Fix Released
Status in OpenStack Compute (nova) kilo series:
  New
Status in OpenStack Security Advisory:
  Fix Released

Bug description:
  This issue is being treated as a potential security risk under
  embargo. Please do not make any public mention of embargoed (private)
  security vulnerabilities before their coordinated publication by the
  OpenStack Vulnerability Management Team in the form of an official
  OpenStack Security Advisory. This includes discussion of the bug or
  associated fixes in public forums such as mailing lists, code review
  systems and bug trackers. Please also avoid private disclosure to
  other individuals not already approved for access to this information,
  and provide this same reminder to those who are made aware of the
  issue prior to publication. All discussion should remain confined to
  this private bug report, and any proposed fixes should be added to the
  bug as attachments.

  There is a qcow2 format vulnerability in LibvirtDriver.snapshot. The
  impact is that on an affected system, an unprivileged api user can
  retrieve any file on the host readable by the nova user. This includes
  guest data of other instances on the same host, and credentials used
  by nova to access other services externally.

  LibvirtDriver.snapshot does:

      source_format = libvirt_utils.get_disk_type(disk_path)
      ...
      snapshot_backend = self.image_backend.snapshot(instance,
          disk_path,
          image_type=source_format)
      ...
      snapshot_backend.snapshot_extract(out_path, image_format)

  libvirt_utils.get_disk_type falls back to image inspection for disks
  which are not lvm, rbd or ploop, which means raw and qcow2 images.

  The vulnerability only exists when a user can write to a raw volume
  which is later erroneously detected as qcow2. This means that the
  vulnerability is only present on systems using the libvirt driver
  which have defined use_cow_images=False in nova.conf. This is not the
  default, so by default nova is not vulnerable.

  libvirt.utils.extract_snapshot() expects to be reading from an
  instance disk and writing to a temporary directory created by nova for
  storing snapshots before transferring them to glance. As nova directly
  creates this directory and its contents, the 'qemu-img convert'
  process does not need to run privileged. This means that the exposure
  is limited to files directly readable by the nova user.

  Unfortunately, as is clear from the context this includes all instance
  data which, despite being owned by the qemu user, is world readable.
  Additionally, because the qemu-img process is executed by nova
  directly, it does not benefit from any confinement by libvirt.
  Specifically, SELinux is not likely to be a defence on a typical
  deployment.

  I have tested this exploit on a Fedora 23 system running devstack as
  of 8th Dec 2015:

  Ensure nova.conf contains use_cow_images = False in the DEFAULT
  section.

  As an unprivileged api user, do:
  $ nova boot --image cirros --flavor m1.tiny foo

  Somewhere, run:
  $ qemu-img create -f qcow2 -o backing_file=/etc/passwd bad.qcow2
  Ensure bad.qcow2 is available in the foo instance.

  Log into foo, and execute as root:
  # dd if=bad.qcow2 of=/dev/vda conv=fsync

  As an unprivileged api user, do:
  $ nova image-create foo passwd
  $ glance image-download <newly created image id> --file passwd

  The unprivileged api now has the contents of /etc/passwd from the host
  locally.

  Mitigations:

  Nova is not vulnerable by default. The user must have configured use_cow_images=False.
  Nova configurations using ceph or lvm for instance storage are not vulnerable.
  An attacker must know the uuid of another user's instance in order to be able to access its data.

To manage notifications about this bug go to:
https://bugs.launchpad.net/nova/+bug/1524274/+subscriptions