From mboxrd@z Thu Jan 1 00:00:00 1970 Received: from eggs.gnu.org ([2001:4830:134:3::10]:39667) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1XnjsR-0001BM-8A for qemu-devel@nongnu.org; Mon, 10 Nov 2014 02:59:13 -0500 Received: from Debian-exim by eggs.gnu.org with spam-scanned (Exim 4.71) (envelope-from ) id 1XnjsL-0001eU-2k for qemu-devel@nongnu.org; Mon, 10 Nov 2014 02:59:07 -0500 Received: from mx1.redhat.com ([209.132.183.28]:34909) by eggs.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1XnjsK-0001eN-RU for qemu-devel@nongnu.org; Mon, 10 Nov 2014 02:59:01 -0500 Received: from int-mx10.intmail.prod.int.phx2.redhat.com (int-mx10.intmail.prod.int.phx2.redhat.com [10.5.11.23]) by mx1.redhat.com (8.14.4/8.14.4) with ESMTP id sAA7wxcQ017322 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-GCM-SHA384 bits=256 verify=FAIL) for ; Mon, 10 Nov 2014 02:58:59 -0500 From: Markus Armbruster References: <87lhnq3iul.fsf@blackfin.pond.sub.org> <5459E210.2020008@redhat.com> <87a944y0od.fsf@blackfin.pond.sub.org> <545B6F4F.4050106@redhat.com> <20141106145658.GD23802@localhost.localdomain> <545B8D0C.4040600@redhat.com> <87lhnn9i6r.fsf@blackfin.pond.sub.org> <545CE26F.4080101@redhat.com> Date: Mon, 10 Nov 2014 08:58:56 +0100 In-Reply-To: <545CE26F.4080101@redhat.com> (Max Reitz's message of "Fri, 07 Nov 2014 16:17:03 +0100") Message-ID: <87d28v4hbz.fsf@blackfin.pond.sub.org> MIME-Version: 1.0 Content-Type: text/plain Subject: Re: [Qemu-devel] Image probing: how it can be insecure, and what we could do about it List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , To: Max Reitz Cc: Kevin Wolf , Jeff Cody , qemu-devel@nongnu.org, Stefan Hajnoczi Max Reitz writes: > On 2014-11-07 at 15:52, Markus Armbruster wrote: >> Max Reitz 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 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".