Re: [Qemu-devel] [PATCH] Make default invocation of block drivers safer

[Stefan Hajnoczi <stefanha@gmail.com>]

On Thu, Jul 15, 2010 at 1:57 PM, Anthony Liguori
<aliguori@linux.vnet.ibm.com> wrote:
> On 07/15/2010 04:10 AM, Stefan Hajnoczi wrote:
>>
>> I have mixed feelings about this approach.  It has good usability
>> because legitimate users are unaffected, but adding a check into the
>> I/O path is unfortunate from a clean code perspective.
>>
>> Management stacks that don't explicitly set format= today are in
>> trouble.  In an environment where the VM owner is untrusted, the VM
>> owner could provide/upload a malicious disk image and cold boot it.
>>
>
> More specifically, management stacks are in trouble if they use raw images
> and don't use format=.  Anyone using qcow2 exclusively is fine.
>
> I'm less concerned about uploaded images.  Format spoofing is really the
> least of the concerns for uploaded images.  The bigger concern IMHO is
> attempting to exploit vulnerabilities in qcow2 or any of the other image
> formats.

Attempting to exploit vulnerabilities in image formats is exactly what
you can do with image spoofing, even though your VM was created with a
raw image.

>
>> This patch only prevents dodgy images created inside a running VM.
>> Luckily this scenario is increasingly unlikely since management stacks
>> specifying explicit format= and SELinux/sVirt will eventually make
>> this go away.
>>
>> I think there are actually two issues here:
>>
>> 1. Confusing QEMU so it sees an image with a different format than
>> expected.
>>
>> This is important because it's unexpected behavior for a user who puts
>> a QCOW2 image onto a raw disk to find the disk itself turn into a
>> QCOW2 disk on next reboot.
>>
>> I also worry about this bug because it means that in a scenario where
>> format= is not explicitly given, the VM can change its disk image
>> format.  This is a problem because the host administrator might have
>> used raw files and be unhappy to find that the user is able to exploit
>> a (hypothetical) security issue in the vmdk code despite having
>> created the VM with a raw image.
>>
>
> One of the nasty things in QEMU right now is that we have absolutely no way
> to persist information about the guest and we have no persistent definition
> of the guest.
>
> All of our VMs are basically stateless across invocations and that really
> makes things like this difficult.
>
>> 2. Image formats that support backing files are inherently insecure.
>>
>> The final scenario that doesn't go away is the casual user who tries
>> out a foreign disk image.  The expectation is that the disk image
>> could boot up and do completely silly things but it could not affect
>> the host.  In reality it can read the contents of any file owned by
>> the uid running QEMU and send them over the internet if the guest has
>> networking.
>>
>> You really need to run qemu-img info to check that there is no
>> unwanted backing file.  So I suspect we'll never be 100% safe unless
>> backing files are disabled by default with an error message asking you
>> to add allow_backing_file=on.
>>
>
> I'm not sure I'd classify it as insecure.  They are only insecure *if* the
> guest can modify the backing file.  With the proposed patch, they can't.

You cannot trust a QCOW2 file I give you, it might read your mailbox
and send me the contents.  This is the offline attack vector again,
not a running VM modifying its disk image and rebooting.

I think it is reasonable to expect a published disk image to be unable
to access local files on the host.

Stefan