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

[Max Reitz <mreitz@redhat.com>]

On 2014-11-07 at 15:52, Markus Armbruster wrote:
> Max Reitz <mreitz@redhat.com> 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 <mreitz@redhat.com> 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."