qemu-block
[Top][All Lists]
Advanced

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

Re: [Qemu-block] [kubevirt-dev] Re: Converting qcow2 image on the fly to


From: Richard W.M. Jones
Subject: Re: [Qemu-block] [kubevirt-dev] Re: Converting qcow2 image on the fly to raw format
Date: Thu, 19 Jul 2018 15:15:18 +0100
User-agent: Mutt/1.5.21 (2010-09-15)

On Thu, Jul 19, 2018 at 04:25:28PM +0300, Nir Soffer wrote:
> On Mon, Jul 16, 2018 at 11:56 AM Daniel P. Berrangé <address@hidden>
> wrote:
> 
> > On Wed, Jul 11, 2018 at 02:17:18PM +0300, Adam Litke wrote:
> > > Adding some kubevirt developers to the thread.  Thanks guys for the
> > > information!  I think this could work perfectly for on the fly conversion
> > > of qcow2 images to raw format on our PVCs.
> >
> > FYI if you are intending to accept qcow2 images from untrustworthy sources
> > you must take special care to validate the image in a confined environment.
> > It is possible to construct malicious images that inflict a denial of
> > service attack on CPU or memory or both, even when merely opening the image
> > to query its metadata. This has been reported as a CVE against OpenStack
> > in the past:
> >
> >   https://bugs.launchpad.net/ossa/+bug/1449062
> >
> > Recommendation is to run 'qemu-img info' to extract the metadata and sanity
> > check results eg no backing file list, not unreasonable size, etc. When
> > running 'qemu-img info' apply process limits of 30 secs CPU time, and 1 GB
> > address space.
> >
> 
> Thanks for the suggestion.
> 
> We currently do not limit the qemu-img process in any way, but it sounds
> like
> a good idea.
> 
> We also don't verify the size of the image, this should be fixed.
> 
> What we do currently is:
> 1. Mark image as illegal in oVirt metadata - prevents using the image by
> oVirt.
> 2. Expose the image via http
> 3. Wait until the user completes the upload
> 4. Unexposed the image, so no more data can be written.
> 5. Run qemu-img info /path/to/image (running as vdsm, but without any limit)
> 6. Verify format with oVirt metada - it must be same as specified in oVirt
> 7. Verify backing file with ovirt metadata - it must be same as specified
> in oVirt
>     (no backing file or volume UUID)
> 8. Verify that qcow2 compat is compatible with the storage domain
> 9. If all checks are ok, mark the image as legal.
> 
> The image is deleted on verification failure.
> 
> This is the code if someone like to check:
> -
> https://github.com/oVirt/vdsm/blob/857df825f8c1e9030f7c1e46e6c59cb63546d7c9/lib/vdsm/storage/hsm.py#L1535
> -
> https://github.com/oVirt/vdsm/blob/857df825f8c1e9030f7c1e46e6c59cb63546d7c9/tests/storage/hsm_test.py#L49

Apart from putting some ulimits around the qemu-img info command I
think this should be fine.

A few weeks ago I spent some time looking closely at the qemu qcow2
code and trying to write a custom malicious qcow2 file to break it,
but I didn't get anywhere.

Rich.

-- 
Richard Jones, Virtualization Group, Red Hat http://people.redhat.com/~rjones
Read my programming and virtualization blog: http://rwmj.wordpress.com
virt-builder quickly builds VMs from scratch
http://libguestfs.org/virt-builder.1.html



reply via email to

[Prev in Thread] Current Thread [Next in Thread]