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.
--- 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.
Created libguestfs tracking bugs for this issue Affects: fedora-all [bug 643991]
First part of the fix posted: https://www.redhat.com/archives/libguestfs/2010-October/msg00037.html
Complete upstream fix posted: https://www.redhat.com/archives/libguestfs/2010-October/thread.html#00041
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