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
Hi everyone, i assume i have found another exploit path:
1. Create the malicious image using qemu-img y.prlimit --as=1073741824 --cpu=30 -- env LC_ALL=C LANG=C qemu-img info /var/lib/ nova/instances/ _base/254082e79 b0aa7619ff786b5 860c71b2a63dd7d c.part --force-share --output=json -f raw` to get some kind of information. This is still save y.prlimit --as=1073741824 --cpu=30 -- env LC_ALL=C LANG=C qemu-img info /var/lib/ nova/instances/ _base/254082e79 b0aa7619ff786b5 860c71b2a63dd7d c --force-share --output=json
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_concurrenc
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_concurrenc
and
env LC_ALL=C LANG=C qemu-img create -f qcow2 -o backing_ file=/var/ lib/nova/ instances/ _base/254082e79 b0aa7619ff786b5 860c71b2a63dd7d c,backing_ fmt=qcow2, cluster_ size=65536 /var/lib/ nova/instances/ 8e144dbd- 9f6f-4c4c- 9388-aa71d61934 08/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.