Comment 155 for bug 2059809

Some more notes:

- I tested the "option 2" from the bug description and it is also working, haven't seen that mentioned before.
- The exploit for nova only works when the option DEFAULT/force_raw_images is True (which is the default). If I set this to False, there is always an error about failing to open the data_file when qemu is being started by nova, not sure if there would be a way to work around that with sufficient trickery.
- With force_raw_images=True I think it is also not possible to get to write any data to the data_file, because nova always converts the base image to raw.
- When trying to exfiltrate data from another instance running on the same host by specifying its disk image as data_file, nova gets confused and throws an error because the converted-to-raw file then still is another qcow2 file.

So in general the impact is: Data extraction from the hypervisor (or the server running the cinder-volume service) is possible, which is very bad, but maybe not quite as bad is it could have been. I still wonder how a responsible disclosure could look like, that doesn't instantaneously but all running clouds at risk. Would a pre-warning urging operators to temporarily disable image uploads help? Should it mention qcow2 or might that be too much of a hint? (And also possibly not enough given what Felix has found?)

I'm also not convinced that the announcement should be delayed too much, but surely the patches should be in a working, stable state. So maybe do a pre-announcement on Thursday (to give us time to find the proper wording) and the full disclosure one week later?