Comment 97 for bug 2059809

After speaking directly to some of the QEMU team members, there is an additional wrinkle/development here. It sounds like they *will* end up providing a patch to qemu-img to prevent the info subcommand from opening external resources purely during that operation. That means that, if so and if successful, the combination of that updated qemu-img binary *plus* the original patches we had to just look for and reject an image with a data-file set in the info blob would be sufficient to close this vulnerability.

That said, they also suggested that OpenStack continue to deeply inspect our images for safety, even to the point of rejecting images with unknown feature flag bits set. Doing so would have prevented the introduction of the data-file feature from becoming an issue for us in the first place, and would provide protection from (or at least detection of) a similar situation in the future.

After speaking with the Nova PTL, the nova plan is going to be to provide two patches. The first will be the same as the original plan, which assumes qemu-img is safe (i.e. patched), and uses it to look for and reject an image with a data-file. The second patch will be as proposed here currently, which runs format_inspector ahead of time to perform the safety check (which will be extended to reject unknown feature flags) to avoid even running qemu-img at all if we find suspicious content.

That plan will mean that anyone not in a position to have a patched qemu binary on disclosure day will be able to deploy just updated nova code and be protected, both for this and future feature-based exposures. Anyone that wants minimal change to their nova package and is able to depend on getting or building an updated qemu-img binary will also be protected against the data-file exploit with just the first small patch. Nova will plan to merge and backport both layers of protection.