From mboxrd@z Thu Jan 1 00:00:00 1970 Received: from eggs.gnu.org ([2001:4830:134:3::10]:50702) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1Xmku1-0005FV-Su for qemu-devel@nongnu.org; Fri, 07 Nov 2014 09:52:48 -0500 Received: from Debian-exim by eggs.gnu.org with spam-scanned (Exim 4.71) (envelope-from ) id 1Xmktr-0000Xx-QT for qemu-devel@nongnu.org; Fri, 07 Nov 2014 09:52:41 -0500 Received: from mx1.redhat.com ([209.132.183.28]:57800) by eggs.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1Xmktr-0000Xc-IV for qemu-devel@nongnu.org; Fri, 07 Nov 2014 09:52:31 -0500 Received: from int-mx14.intmail.prod.int.phx2.redhat.com (int-mx14.intmail.prod.int.phx2.redhat.com [10.5.11.27]) by mx1.redhat.com (8.14.4/8.14.4) with ESMTP id sA7EqUk4014257 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-GCM-SHA384 bits=256 verify=FAIL) for ; Fri, 7 Nov 2014 09:52:31 -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> Date: Fri, 07 Nov 2014 15:52:28 +0100 In-Reply-To: <545B8D0C.4040600@redhat.com> (Max Reitz's message of "Thu, 06 Nov 2014 16:00:28 +0100") Message-ID: <87lhnn9i6r.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-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! > 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.