On 2/24/20 5:01 AM, Peter Krempa wrote:
> On Sat, Feb 22, 2020 at 05:23:38 -0600, Eric Blake wrote:
>> In the past, we have had CVEs caused by qemu probing one image type
>> when an image started out as another but the guest was able to modify
>> content. The solution to those CVEs was to encode backing format
>> information into qcow2, to ensure that once we make a decision, we
>> don't have to probe any further. However, we failed to enforce this
>> at the time. And now that libvirt is switching to -blockdev, it has
>> come back to bite us: with -block, libvirt had no easy way (other than
>
> s/-block/-drive/ ?
Whoops, yes.
>
>> json:{} pseudoprotocol) to force a backing file, but with -blockdev,
>
> "json:{}" is basically -blockdev with extra steps. Old -drive usage
> didn't have any way to do that apart from rewriting the image. Which is
> basically the same since json:{} also needs to be recorded in the image
> to take effect.
Discussed in my other reply (it looks like I'll need to distinguish
between json: pointing to just a protocol as the backing layer, vs. the
more typical json: pointing to a format as the backing layer).
>
>> libvirt HAS to use blockdev-open on the backing chain and supply a
>> backing format there, and thus has to probe images. If libvirt ever
>> probes differently than qemu, we are back to the potential
>> guest-visible data corruption or potential host CVEs.
>
> As I've elaborated in [1] I disagree with the host CVE part. The
> insecure part is not probing the format itself, but probing format AND
> using the backing file of the image if we probed format.
>
> I agree that mis-probing format leads to data corruption though.
Your argument that there are other means at hand to prevent CVE when
probing does occur is valid, however, my point is that CVEs due to
probing were historically possible if the rest of the toolchain is not
careful. It is more of a burden-shifting problem: when qemu is not
preventing probing, then other applications like libvirt have to take on
extra measures to ensure libvirt does not have a CVE (the fact that we
haven't had any in a few years is a good sign that we are at least aware
of the problem and have worked hard to remain safe, even if it has
required duplicated effort across multiple tools); whereas if qemu takes
a hard-line stance on probing (which is the goal of the deprecation
introduced in this series), now qemu has ensured safety whether or not
the other layers also take measures to avoid any CVE.
>
>> It's time to deprecate images without backing formats. This patch
>> series does two things: 1. record an implicit backing format where one
>> is learned (although sadly, not all qemu-img commands are able to
>> learn a format), 2. warn to the user any time a probe had ambiguous
>> results or a backing format is omitted from an image. All previous
>> images without a backing format are still usable, but hopefully the
>> warnings (along with libvirt's complaints about images without a
>> backing format) help us pinpoint remaining applications that are
>
> It is not a warning in libvirt though. We just refuse it now because we
> don't do probing. Previously we allowed qemu to probe the format and the
> only thing that prevented host CVEs was if the host used selinux or any
> other security approach which would prevent opening the backing file.
>
>> creating images on their own without recording a backing format.
--
Eric Blake, Principal Software Engineer
Red Hat, Inc. +1-919-301-3226
Virtualization: qemu.org | libvirt.org