Comment 143 for bug 2059809

Hi everyone, i assume i have found another exploit path:

1. Create the malicious image using qemu-img
2. openstack image create --disk-format raw --file malicious.qcow2 malicious-image
   * this will upload the image to glance
   * since disk-format is specified as raw glance will treat it as raw and basically not check anything
   * note that image conversion is not enabled here
3. openstack server create --image malicious-image exploited-server --flavor c1.1
4. The server will start spawning on the hypervisor
5. nova downloads the image and uses `/usr/bin/python3 -m oslo_concurrency.prlimit --as=1073741824 --cpu=30 -- env LC_ALL=C LANG=C qemu-img info /var/lib/nova/instances/_base/254082e79b0aa7619ff786b5860c71b2a63dd7dc.part --force-share --output=json -f raw` to get some kind of information. This is still save
6. nova then tries to create a qcow2 file for the server based on this base file. Here the information on the format seems lost. I see the following calls in the nova-compute log:
```
/usr/bin/python3 -m oslo_concurrency.prlimit --as=1073741824 --cpu=30 -- env LC_ALL=C LANG=C qemu-img info /var/lib/nova/instances/_base/254082e79b0aa7619ff786b5860c71b2a63dd7dc --force-share --output=json

and

env LC_ALL=C LANG=C qemu-img create -f qcow2 -o backing_file=/var/lib/nova/instances/_base/254082e79b0aa7619ff786b5860c71b2a63dd7dc,backing_fmt=qcow2,cluster_size=65536 /var/lib/nova/instances/8e144dbd-9f6f-4c4c-9388-aa71d6193408/disk
```

note the call to "qemu-img info" without a specific format and the wrong backing_fmt afterwards (should be raw).

I assume we need to patch nova/virt/libvirt/utils.py:create_image to take an expected backing_file format.

While this was tested on zed the code on master looks like it would have the same issue.

I'll try to build a patch for this as well, but no idea how long i will take.