[Date Prev][Date Next]   [Thread Prev][Thread Next]   [Thread Index] [Date Index] [Author Index]

[libvirt] [PATCH 00/11] CVE: Multiple flaws in disk handling



This patch series attempts to fix 3 security flaws in the handling
of virtual disk formats. This is just another occurrance of the
problem previously identified in Xen

  https://www.redhat.com/security/data/cve/CVE-2008-2004.html

In essence, if a guest is configured with a disk, hda, backed in
the host by a plain file, then admin in the guest OS can run
'qemu-img -f qcow2 /dev/hda' to write a qcow2 header into the disk.
If the host OS ever probes the backing file to identify its format,
then it will see it as a qcow2 file now, instead of the expected
raw.

In QEMU this problem is addressed in two ways

 - When configuring a guest with -drive, always set format=raw|qcow2|etc
   Libvirt will always set this when <driver type='raw|qcow2|etc'>
   is set for a disk.

 - When creating a qcow2 guest, always set an explicit backing
   store format with -o backing_store_format=raw|qcow2|etc
   or -F raw|qcow2|etc. Libvirt will always set this when a
   <format type='raw|qcow2'/> is set for a volume backing store

Despite having support for these QEMU features to prevent probing,
there are flaws in the way libvirt handles disks in various places.

 - In the security drivers (SELinux, CGroups, DAC) when labelling
   files on the host, instead of looking at the <driver type='raw|qcow2'/>
   in the XML to identify the disk format, libvirt probes the file for
   magic data. Thus even if the app has taken the care to set an
   explicit format, for all disks, libvirt can be tricked into setting
   security labels on files that it shouldn't. If the guest OS somehow
   manages to break out and compromise QEMU it can take advantage of
   this labelling flaw to access files it shouldn't.

 - In the security drivers (SELinux, CGroups, DAC) when labelling
   the backing store for files on the host, instead of looking at
   embedded backing store format in the master disk image, libvirt
   probes magic data. Thus even if the app has taken the care to set
   an explicit format, for all disk backing stores, libvirt can be
   tricked into setting security labels on files that it shouldn't.
   If the guest OS somehow manages to break out and compromise QEMU
   it can take advantage of this labelling flaw to access files it
   shouldn't.

 - In the storage driver that creates qcow2 files, the backing store
   format is only set explicitly if the kvm-img binary is found. Any
   users with just a qemu-img binary will not have the backing store
   format set, even if qemu-img supports this capability.

As a general matter of policy, libvirt does not mandate use of the
<driver type='raw|qcow2'/> tag in the XML for disks, and if omitted
will allow QEMU to probe disk formats. This is a weak default policy.
If no explicit driver is set, libvirt should presume raw, since that
is the only safe option. It should require a host level configuration
option for the QEMU driver, to allow probing to be used.


This patch series addresses all three of the security flaws, and also
changes the default QEMU driver policy to disable all disk format
probing out of the box. This latter change will break some existing
deployments, so it is possible to turn it off in qemu.conf.

The changes required significant re-factoring of the util/storage_file.c
code and centralizes all processing of disk backing stores to minimise
the risk of mistakes.

There are also 5 additional test cases to the TCK, 3 to verify the
security flaws, and 2 to verify that libvirtd is configured to disallow
disk format probing.

The file based storage pool needs to report the format of every volume
in the pool. There is no way todo this other than to probe the volume
metadata. Unfortunately if an application like virt-manager directly
copies the <format> from the storage volume XML, straight into the
<driver type=> of the guest disk, all our work to avoid the security
problems is potentially null & void. NB, this is only a problem if
re-using a pre-existing storage volume. If creating a new storage vol
when provisioning a guest / hotplugging a disk, virt-manager can trust
the storage volume format.

I think we need to advise applications that when picking a pre-existing
storage volume from a pool, they must not trust the volume format, and
must confirm with the user whether to use the probed format, or force to
raw

The CVEs are

  https://bugzilla.redhat.com/show_bug.cgi?id=CVE-2010-2237
  https://bugzilla.redhat.com/show_bug.cgi?id=CVE-2010-2238
  https://bugzilla.redhat.com/show_bug.cgi?id=CVE-2010-2239

In addition, this patch series fixes the problem of mutually recursive
backing stores which would cause an infinite loop in libvirtd.

Regards,
Daniel


[Date Prev][Date Next]   [Thread Prev][Thread Next]   [Thread Index] [Date Index] [Author Index]