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-07 at 15:52, Markus Armbruster wrote:
>> 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!
>
> Why not?
>
> "It's the default due to legacy, but it's your fault if something breaks."

Sorry, I'm not cynical enough to see it that way.

Dangerous feature: if we really think users shouldn't use X unless they
really know what they're doing, then we should require users to
explicitly choose X.

Here, the danger is "it's your fault if something breaks".