qemu-devel
[Top][All Lists]
Advanced

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

Re: [Qemu-devel] Image probing: how it can be insecure, and what we coul


From: Markus Armbruster
Subject: Re: [Qemu-devel] Image probing: how it can be insecure, and what we could do about it
Date: Wed, 05 Nov 2014 08:04:59 +0100
User-agent: Gnus/5.13 (Gnus v5.13) Emacs/24.3 (gnu/linux)

Jeff Cody <address@hidden> writes:

> On Tue, Nov 04, 2014 at 07:45:38PM +0100, Markus Armbruster wrote:
[...]
>> == Don't guess format from untrusted image contents ==
>> 
>> Several variations of the theme.
>> 
>> Guessing only happens when the user doesn't specify a format, so the
>> simplest way to avoid it would be requiring users to always specify the
>> format.
>> 
>> PRO: Simple, plugs the hole.
>> 
>> CON: Breaks a lot of existing usage.  Bye -hda, hello extra typing.
>> 
>> Variation: command line option to opt out of probing completely.
>> 
>> PRO: Simple, plugs the hole.
>> 
>> CON: Insecure by default.
>> 
>> CON: In addition to opting out, you have to update your usage
>> accordingly.  I guess libvirt would do it anyway, to guard against
>> accidental probing once and for all.
>> 
>> Variation: Stefan proposed to make format= mandatory just for -drive.  I
>> guess he rather meant mandatory for anything but -hda and other selected
>> convenience interfaces.
>> 
>> PRO: No extra typing in the cases where it makes the most difference.
>> 
>> CON: Breaks existing usage in the other cases, extra typing.
>> 
>> CON: Doesn't fully plug the hole.  Users of convenience interfaces may
>>     remain insecure out of ignorance.  We could add a warning to guide
>>     them to more secure usage, but then that warning would annoy users
>>     who don't care for security (sometimes with reason), and we can't
>>     have that.  So we silently leave the users who would care if they
>>     knew insecure.
>> 
>> I proposed something less radical, namely to keep guessing the image
>> format, but base the guess on trusted meta-data only: file name and
>> attributes.  Block and character special files are raw.  For other
>> files, find the file name extension, and look up the format claiming it.
>> 
>> PRO: Plugs the hole.
>> 
>> CON: Breaks existing usage when the new guess differs from the old
>>     guess.  Common usage should be fine:
>> 
>>     * -hda test.qcow2
>> 
>>       Fine as long as test.qcow2 is really QCOW2 (as it should!), and
>>       either specifies a backing format (as it arguably should), or the
>>       backing file name is sane.
>> 
>>     * -hda disk.img
>> 
>>       Fine as long as disk.img is really a disk image (as it should).
>> 
>>     * -hda /dev/mapper/vg0-virtdisk
>> 
>>       Fine as long as the logical volume is raw.
>> 
>>     Less common usage can break:
>> 
>>     * -hda nbd://localhost
>> 
>>       Socket provides no clue, so no guess.
>> 
>>     Weird usage can conceivably break hard:
>> 
>>     * -hdd disk.img
>> 
>>       Breaks hard when disk.img is actually QCOW2, the guest boots
>>       anyway from another drive, then proceeds to overwrite this one.
>> 
>> Mitigation: lengthy transition period where we warn "this usage is
>> insecure, and we'll eventually break it; here's a hint on secure usage".
>> 
>> CON: We delay plugging the hole one more time.  But at least we no
>> longer expose our users to it silently.
>> 
>> Jeff pointed out that we want to retain probing in things like qemu-img
>> info.
>> 
>> Richard asked for a way for users to ask for insecure probing, say
>> format=insecure-probe.  I have no problem with giving users rope when
>> they ask for it.
>> 
>> Variation: if file name and attributes are unavailable or provide no
>> clue, guess raw.  Same PRO and CON as above, only it avoids breaking a
>> few more cases.  For instance, "-hda nbd://localhost" keeps working as
>> long as the server serves a raw image.  Smells a bit like too much magic
>> to me.
>>
>
> How about another variation: probe as we do currently, but a
> result of 'raw' is a hard failure ("Unable to determine image format,
> it may be 'raw'.  You must specify the image format").
>
> This makes sense, because of a probe result of raw currently really
> means "I don't recognize this image", so maybe we should just treat it
> as such.
>
> Imagine two different QEMU binaries, with different image formats
> compiled in.  Currently, by detecting "raw" we could cause data
> corruption in a guest, if one QEMU version doesn't recognize 'foobar'
> image format.

I like the honesty of letting probing yield "I don't know", and the
general simplicity.

> PRO: 
> * Simple, and non-raw format probes will continue to behave the same
>
> * We stop "guessing" raw
>
> CON: 
> * User could specify format of "raw", have a guest write an image
> header to sector 0, and then in subsequent usage go back to probing

Yes, it doesn't fully plug the hole, just like Kevin's proposal.  Thus,
it can't satisfy my "secure usage should not be hard" requirement on its
own.

> * Will break some scripts

It'll break common usage like -cdrom r7.iso and -hda foo.img.

>> My proposal replaces probing wholesale.  I like that because it results
>> in simple, predictable guessing.  Here's a hybrid approach: first guess
>> raw vs. non-raw based on trusted meta-data only, and if non-raw, probe.
>> 
>> Nothing the guest writes can affect the raw vs. non-raw decision.  Once
>> an image is raw, only the user can make it non-raw, by changing its name
>> or attributes.
>> 
>> Two variations: 1. guess raw without a clue, and 2. guess non-raw then.
>> 
>> Again, same PRO and CON as above, only it doesn't break when users give
>> their non-raw images weird names.
[...]



reply via email to

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