From mboxrd@z Thu Jan 1 00:00:00 1970 Received: from eggs.gnu.org ([2001:4830:134:3::10]:41623) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1Xnk6L-0004GP-My for qemu-devel@nongnu.org; Mon, 10 Nov 2014 03:13:35 -0500 Received: from Debian-exim by eggs.gnu.org with spam-scanned (Exim 4.71) (envelope-from ) id 1Xnk6D-0006aq-Nt for qemu-devel@nongnu.org; Mon, 10 Nov 2014 03:13:29 -0500 Received: from mx1.redhat.com ([209.132.183.28]:49548) by eggs.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1Xnk6D-0006Zt-G9 for qemu-devel@nongnu.org; Mon, 10 Nov 2014 03:13:21 -0500 Received: from int-mx09.intmail.prod.int.phx2.redhat.com (int-mx09.intmail.prod.int.phx2.redhat.com [10.5.11.22]) by mx1.redhat.com (8.14.4/8.14.4) with ESMTP id sAA8DKgK023775 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-GCM-SHA384 bits=256 verify=FAIL) for ; Mon, 10 Nov 2014 03:13:20 -0500 From: Markus Armbruster References: <87lhnq3iul.fsf@blackfin.pond.sub.org> <20141105110140.GC6198@noname.str.redhat.com> <87tx2csa8c.fsf@blackfin.pond.sub.org> <20141106150121.GD4409@noname.redhat.com> <878ujn9gu5.fsf@blackfin.pond.sub.org> Date: Mon, 10 Nov 2014 09:13:18 +0100 In-Reply-To: <878ujn9gu5.fsf@blackfin.pond.sub.org> (Markus Armbruster's message of "Fri, 07 Nov 2014 16:21:38 +0100") Message-ID: <87wq73323l.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: Kevin Wolf Cc: Jeff Cody , qemu-devel@nongnu.org, Stefan Hajnoczi , Max Reitz Markus Armbruster writes: [...] > let me refine / vary the hybrid approach I mentioned > under " Don't guess format from untrusted image contents" some. I think > I can trace some inspiration to Max here. > > Say we use trusted meta-data to compute a set of admissible formats, and > if the set has multiple members, use probing to pick one of them. > > Example: foo.qcow2 -> { qcow2 }, no probing > > Example: foo.qcow -> { qcow, qcow2 }, probe to pick one > > Likewise for foo.vhdx and foo.vhd. > > To ensure this actually knocks out condition (b), all members of the set > must have the image contents used by their members' probes within their > trust boundary. > > Example: { qcow, qcow2 } is fine, because both formats have a header, > and each header covers the bytes either probe examines. > > Example: { raw } is fine, because there is no probing. > > Counterexample: { raw, qcow2 } is not possible, because qcow2 probes > outside raw's trusted metadata. > > Note my careful wording "contents used by [other] probes". Right now we > simply assume that the first 2048 bytes can be trusted. This is not > obviously the case! If I remember correctly, you proposed to cut it to > 512 bytes, which feels a lot safer, since any sane format probably > aligns (untrusted) image contents to at least a 512 byte boundary, but > is still theoretically unsound. > > PRO and CON like my proposal to guess from trusted meta-data only. The > difference is in what existing usage exactly it breaks. > > Can be combined with "refuse to use a format without an explicit format= > when any other non-raw format probe accepts", just like everything else > proposed so far. Can also be mitigated: lengthy transition period where we warn "this usage is insecure, and we'll eventually break it; here's a hint on secure usage". [...]