Bug 643958 (CVE-2010-3851) - CVE-2010-3851 libguestfs: missing disk format specifier when adding a disk
Summary: CVE-2010-3851 libguestfs: missing disk format specifier when adding a disk
Keywords:
Status: CLOSED ERRATA
Alias: CVE-2010-3851
Product: Security Response
Classification: Other
Component: vulnerability
Version: unspecified
Hardware: All
OS: Linux
low
low
Target Milestone: ---
Assignee: Red Hat Product Security
QA Contact:
URL:
Whiteboard:
Depends On: 641008 643990 643991
Blocks:
TreeView+ depends on / blocked
 
Reported: 2010-10-18 16:06 UTC by Petr Matousek
Modified: 2019-09-29 12:40 UTC (History)
7 users (show)

Fixed In Version:
Doc Type: Bug Fix
Doc Text:
Clone Of:
Environment:
Last Closed: 2015-06-04 14:35:08 UTC
Embargoed:


Attachments (Terms of Use)


Links
System ID Private Priority Status Summary Last Updated
Red Hat Product Errata RHSA-2011:0586 0 normal SHIPPED_LIVE Low: libguestfs security, bug fix, and enhancement update 2011-05-19 11:44:03 UTC

Description Petr Matousek 2010-10-18 16:06:07 UTC
Libguestfs doesn't currently allow the format of a disk to be specified explicitly. Because of that malicious guest admin can exploit automatic image format detection in qemu, when the libguestfs is used to administer the image, to read arbitrary file on host via forging a image header with backing store.

Comment 1 Petr Matousek 2010-10-18 16:21:26 UTC
--- Additional comment from rjones on 2010-10-07 17:13:27 EDT ---

The risk seems to be as follows:

(1) Malicious guest is using a raw-format disk image.

(2) Guest writes a carefully crafted qcow2, VMDK or VDI header
into their own raw disk, and also replaces some binary that one
of our tools might run (/usr/bin/rpm would be a good candidate).
The header says that this (fake) qcow2 image is backed by some
other host file that the guest is interested in reading, eg.
/etc/passwd.  The binary is changed so it reads the backing file
and squirrels the information away somewhere for later use.

(3) Some libguestfs tool runs against the guest.  This tool must
combine the qualities (a || b) && c:
  (a) It opens the guest read-write using guestfs_add_drive _or_
  (b) it enables networking with guestfs_set_network, _and_
  (c) it runs the chosen binary from the guest.

(4) The chosen binary is able to read the backing file (/etc/passwd)
and either store that for later use in the writable disk image or
send it over the network.

I believe that virt-v2v is the only upstream libguestfs-related tool
which is vulnerable, although it's possible boxgrinder is too.

In addition, in RHEL 6.0 networking is always enabled, and that
makes virt-inspector vulnerable as well.

--- Additional comment from pmatouse on 2010-10-08 13:33:31 EDT ---

(In reply to comment #0)
> However, if a malicious guest administrator knows that
> libguestfs will run against their image, they could still use this technique to
> corrupt the host.

My understanding is that there can't be any corruption of host files because of
the COW nature of the backing store. So only host files content leakage is
possible. Can you please confirm this?

--- Additional comment from pmatouse on 2010-10-08 13:36:30 EDT ---

Maybe libguestfs could (apart from explicitly setting the format on command
line) parse libvirt VM configuration files and take the image format from
there? I guess libvirt and libguestfs are often used in conjuction (well, at
least I do that) for VMs administering tasks.

--- Additional comment from rjones on 2010-10-08 13:59:44 EDT ---

(In reply to comment #2)
> My understanding is that there can't be any corruption of host files because of
> the COW nature of the backing store. So only host files content leakage is
> possible. Can you please confirm this?

It is true that the backing file will not be written to under
any circumstances. This is because libguestfs does not use or
expose the 'commit' functionality of qemu.

I think Matt was mistaken when he said that a malicious guest
could "corrupt the host".  The worst that can happen is that
virt-v2v exits with an error, and this could happen anyway
even without backing files.

The concern in this BZ is that the guest could _read_ a host file,
squirrel that information away somewhere, and next time it
boots use that information for nefarious purposes.  eg. Reading
a password file and trying to crack the passwords at next boot,
or reading a database file and sending that over the network.

(In reply to comment #3)
> Maybe libguestfs could (apart from explicitly setting the format on command
> line) parse libvirt VM configuration files and take the image format from
> there? I guess libvirt and libguestfs are often used in conjuction (well, at
> least I do that) for VMs administering tasks.

Yes, we intend to make this change.  Where libvirt knows the intended
guest format, we will pass that along to qemu (which we are not
doing now).

The open issue is what to do about disk images where we don't
have this information, for example disk images that just exist
on disk and are not associated with a libvirt domain.

Comment 3 Petr Matousek 2010-10-18 18:12:43 UTC
Created libguestfs tracking bugs for this issue

Affects: fedora-all [bug 643991]

Comment 4 Vincent Danen 2010-10-21 19:53:24 UTC
First part of the fix posted:

https://www.redhat.com/archives/libguestfs/2010-October/msg00037.html

Comment 5 Richard W.M. Jones 2010-10-22 15:01:49 UTC
Complete upstream fix posted:

https://www.redhat.com/archives/libguestfs/2010-October/thread.html#00041

Comment 10 errata-xmlrpc 2011-05-19 13:10:42 UTC
This issue has been addressed in following products:

  Red Hat Enterprise Linux 6

Via RHSA-2011:0586 https://rhn.redhat.com/errata/RHSA-2011-0586.html


Note You need to log in before you can comment on or make changes to this bug.