Bug 607812 - (CVE-2010-2239) CVE-2010-2239 libvirt: not setting user defined backing store format when creating new image
CVE-2010-2239 libvirt: not setting user defined backing store format when cre...
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=20100712,reported=20100615,sou...
: Security
Depends On: 607817 613061 613625 619104
Blocks:
  Show dependency treegraph
 
Reported: 2010-06-24 18:03 EDT by Petr Matousek
Modified: 2016-04-26 11:38 EDT (History)
11 users (show)

See Also:
Fixed In Version:
Doc Type: Bug Fix
Doc Text:
Story Points: ---
Clone Of:
Environment:
Last Closed: 2015-07-29 10:55:18 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-06-24 18:03:29 EDT
It was found that libvirt did not explicitly set the user defined backing store
format when creating new image. This results in images being created with an
potentialy insecure configuration, preventing applications from opening backing
stores without resorting to probing. A priviledged guest user could use this flaw
to access arbitrary files on the host.
Comment 3 Petr Matousek 2010-07-12 07:27:47 EDT
This issue affects libvirt >= 0.6.0.
Comment 5 Petr Matousek 2010-07-12 09:03:27 EDT
Created libvirt tracking bugs for this issue

Affects: fedora-all [bug 613625]
Comment 6 Fedora Update System 2010-07-26 22:36:44 EDT
libvirt-0.8.2-1.fc13 has been pushed to the Fedora 13 stable repository.  If problems still persist, please make note of it in this bug report.
Comment 7 Fedora Update System 2010-07-26 22:48:41 EDT
libvirt-0.8.2-1.fc12 has been pushed to the Fedora 12 stable repository.  If problems still persist, please make note of it in this bug report.
Comment 9 errata-xmlrpc 2010-08-10 13:02:42 EDT
This issue has been addressed in following products:

  Red Hat Enterprise Linux 5

Via RHSA-2010:0615 https://rhn.redhat.com/errata/RHSA-2010-0615.html
Comment 10 Vincent Danen 2010-08-10 16:52:17 EDT
Statement:

(none)
Comment 11 wangyimiao 2010-08-23 00:53:10 EDT
Verified passed this bug whith:
libvirt-0.8.1-21.el6.x86_64
qemu-kvm-0.12.1.2-2.108.el6.x86_64
qemu-img-0.12.1.2-2.108.el6.x86_64
kernel-2.6.32-59.1.el6.x86_64.

Steps:
1. Prepare two image file, one is qcow2, another is raw.

# qemu-img create -f qcow2 /var/lib/libvirt/images/backstore.img.orignal

Write some thing into the image file via qemu-io.
# qemu-io /var/lib/libvirt/images/backstore.img.orignal 1M
qemu-io> write 0 64K -P65

# qemu-img info backstore.img.orignal
image: backstore.img.orignal
file format: qcow2
virtual size: 1.0M (1048576 bytes)
disk size: 272K
cluster_size: 65536

# qemu-img create -f raw /var/lib/libvirt/images/backstore.img.replace 1M

Write some thing into the image file via qemu-io.
# qemu-io /var/lib/libvirt/images/backstore.img.replace
qemu-io> write 0 64K -P66

# qemu-img info backstore.img.replace
image: backstore.img.replace
file format: raw
virtual size: 1.0M (1048576 bytes)
disk size: 72K

2. Prepare a vol xml with backing store set to some file in host.
# cat vol.xml 
<volume>
  <name>bug.img</name>
  <key>/var/lib/libvirt/images/bug.img</key>
  <source>
  </source>
  <capacity>1048576</capacity>
  <allocation>147456</allocation>
  <target>
    <path>/var/lib/libvirt/images/bug.img</path>
    <format type='qcow2'/>
  </target>
  <backingStore>
    <path>/var/lib/libvirt/images/backstore.img</path>
    <format type='qcow2'/>
  </backingStore>
</volume>

3. Copy the qcow2 image file as backing store file.
# cp backstore.img.orignal backstore.img

4. Create volume via virsh command:
# virsh vol-create default vol.xml
Vol bug.img created from vol.xml

5. Replace the original qcow2 backing store file with a raw image file with the
same name.
# cp backstore.img.replace backstore.img

6. Attach the vol created in step 4 to guest as a secondary disk, and start
guest.
9. Try to start guest.
# virsh start test 
error: Failed to start domain test
error: internal error Process exited while reading console log output: char
device redirected to /dev/pts/3
qemu: could not open disk image /var/lib/libvirt/images/bug.img: Inappropriate
ioctl for device

The doamin can not start.
Comment 12 Daniel Berrange 2010-10-29 07:04:17 EDT
Another more explicit way to validate this bug is to check the contents of the Qcow2 header. The header should contain a string specifying the format of the backing store

Start with 3 xml files

# cat vol0.xml
<volume>
  <name>vol0.img</name>
  <capacity>1048576</capacity>
  <allocation>0</allocation>
  <target>
    <path>/var/lib/libvirt/images/vol0.img</path>
    <format type='qcow2'/>
  </target>
</volume>

# cat vol1.xml 
<volume>
  <name>vol1.img</name>
  <capacity>1048576</capacity>
  <allocation>0</allocation>
  <target>
    <path>/var/lib/libvirt/images/vol1.img</path>
    <format type='qcow2'/>
  </target>
  <backingStore>
    <path>/var/lib/libvirt/images/vol0.img</path>
  </backingStore>
</volume>

# cat vol2.xml 
<volume>
  <name>vol2.img</name>
  <capacity>1048576</capacity>
  <allocation>0</allocation>
  <target>
    <path>/var/lib/libvirt/images/vol2.img</path>
    <format type='qcow2'/>
  </target>
  <backingStore>
    <path>/var/lib/libvirt/images/vol0.img</path>
    <format type='qcow2'/>
  </backingStore>
</volume>

Notice that vol1.xml does not specify a backing storage format. So in the case of vol1, we should see backing format of 'raw', and for vol2, we should see backing format of 'qcow2'.  With old broken libvirt, we don't see either in the qemu file.

Now create the volumes

# virsh vol-create default vol0.xml
Vol vol0.img created from vol0.xml

# virsh vol-create default vol1.xml
Vol vol1.img created from vol1.xml

# virsh vol-create default vol2.xml
Vol vol2.img created from vol2.xml


Now examine the headers either be opening the binary, or quicker by using 'strings'.

# strings -n 3 /var/lib/libvirt/images/vol0.img 
QFI

# strings -n 3 /var/lib/libvirt/images/vol1.img 
QFI
raw
/var/lib/libvirt/images/vol0.img

# strings -n 3 /var/lib/libvirt/images/vol2.img 
QFI
qcow2
/var/lib/libvirt/images/vol0.img


Now compare to what old libvirt would have done

# strings -n 3 /var/lib/libvirt/images/vol1.img 
QFI
/var/lib/libvirt/images/vol0.img

# strings -n 3 /var/lib/libvirt/images/vol2.img 
QFI
/var/lib/libvirt/images/vol0.img

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