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

[Markus Armbruster]

Max Reitz <address@hidden> writes:

> On 2014-11-06 at 15:56, Jeff Cody wrote:
>> On Thu, Nov 06, 2014 at 01:53:35PM +0100, Max Reitz wrote:
>>> On 2014-11-06 at 13:26, Markus Armbruster wrote:
>>>> Max Reitz <address@hidden> writes:
>>>>
>>>>> On 2014-11-04 at 19:45, Markus Armbruster wrote:
[...]
>>>>>> = How this lets the guest escape isolation =
>>>>>>
>>>>>> Unfortunately, this lets the guest shift the trust boundary and escape
>>>>>> isolation, as follows:
>>>>>>
>>>>>> * Expose a raw image to the guest (whether you specify the format=raw or
>>>>>>     let QEMU guess it doesn't matter).  The complete contents becomes
>>>>>>     untrusted.
>>>>>>
>>>>>> * Reuse the image *without* specifying the raw format.  QEMU guesses the
>>>>>>     format based on untrusted image contents.  Now QEMU guesses a format
>>>>>>     chosen by the guest, with meta-data chosen by the guest.  By
>>>>>>     controlling image meta-data, the malicious guest can access arbitrary
>>>>>>     files as QEMU, enlarge its storage, and more.  A non-malicious guest
>>>>>>     can accidentally DoS itself, by writing a pattern probing recognizes.
>>>>> Thank you for bringing that to my attention. This means that I'm even
>>>>> more in favor of using Kevin's patches because in fact they don't
>>>>> break anything.
>>>> They break things differently.  The difference may or may not matter.
>>>>
>>>> Example: innocent guest writes a recognized pattern.
>>>>
>>>>    Now: next restart fails, guest DoSed itself until host operator gets
>>>>    around to adding format=raw to the configuration.  Consequence:
>>>>    downtime (probably lengthy), but no data corruption.
>>>>
>>>>    With Kevin's patch: write fails, guest may or may not handle the
>>>>    failure gracefully.  Consequences can range from "guest complains to
>>>>    its logs (who cares)" via "guest stops whatever it's doing and refuses
>>>>    to continue until its hardware gets fixed (downtime as above)" to
>>>>    "data corruption".
>>> You somehow seem convinced that writing to sector 0 is a completely
>>> normal operation. For x86, it isn't, though.
>>>
>>> There are only a couple of programs which do that, I can only think
>>> of partitioning and setting up boot loaders. There's not a myriad of
>>> programs which would increase the probability of one both writing a
>>> recognizable pattern *and* not handling EPERM correctly.
>>>
>>> I see the probability of both happening at the same time as
>>> extremely low, not least because there are only a handful of
>>> programs which access that sector.
>>>
>> I'm not yet opposed to the "restricted-raw" method, but...
>>
>> I think the above is a somewhat dangerous viewpoint to take with QEMU.
>> It is a bit of a slippery slope to start to assume what data guests
>> will write to the disks provided to them.  Even if the probability of
>> this happening is very low, with what usage we envision now, it is
>> still entirely legitimate usage for a guest to write data starting at
>> sector 0.

Yup.

> Then let's officially deprecate format probing, if we haven't done so
> already. That way, there's no excuse.

I'd gladly deprecate format probing, or at least format probing
resulting in raw.  However, we can hardly deprecate something and keep
it the default behavior!

> What I'm saying is that there are obviously no compatibility
> issues. There is no guest software which did write recognizable
> patterns (so far nobody provided a counterexample), and since format
> probing is deprecated (or should be), you have no excuse for running
> future guests in qemu without having explicitly specified the format.
>
> And if you are specifying the format, Kevin's patches will not prevent
> the guest from making its disk a qcow2 image whatsoever.