Bug 643958 - (CVE-2010-3851) CVE-2010-3851 libguestfs: missing disk format specifier when adding a disk
CVE-2010-3851 libguestfs: missing disk format specifier when adding a disk
Status: CLOSED ERRATA
Product: Security Response
Classification: Other
Component: vulnerability (Show other bugs)
unspecified
All Linux
low Severity low
: ---
: ---
Assigned To: Red Hat Product Security
public=20101014,reported=20101007,sou...
: Security
Depends On: 641008 643990 643991
Blocks:
  Show dependency treegraph
 
Reported: 2010-10-18 12:06 EDT by Petr Matousek
Modified: 2015-08-19 04:58 EDT (History)
7 users (show)

See Also:
Fixed In Version:
Doc Type: Bug Fix
Doc Text:
Story Points: ---
Clone Of:
Environment:
Last Closed: 2015-06-04 10:35:08 EDT
Type: ---
Regression: ---
Mount Type: ---
Documentation: ---
CRM:
Verified Versions:
Category: ---
oVirt Team: ---
RHEL 7.3 requirements from Atomic Host:


Attachments (Terms of Use)

  None (edit)
Description Petr Matousek 2010-10-18 12:06:07 EDT
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 12:21:26 EDT
--- Additional comment from rjones@redhat.com 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@redhat.com 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@redhat.com 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@redhat.com 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 14:12:43 EDT
Created libguestfs tracking bugs for this issue

Affects: fedora-all [bug 643991]
Comment 4 Vincent Danen 2010-10-21 15:53:24 EDT
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 11:01:49 EDT
Complete upstream fix posted:

https://www.redhat.com/archives/libguestfs/2010-October/thread.html#00041
Comment 10 errata-xmlrpc 2011-05-19 09:10:42 EDT
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.