From mboxrd@z Thu Jan 1 00:00:00 1970 Received: from eggs.gnu.org ([2001:4830:134:3::10]:58330) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1XlFZl-0006Zi-W8 for qemu-devel@nongnu.org; Mon, 03 Nov 2014 06:13:40 -0500 Received: from Debian-exim by eggs.gnu.org with spam-scanned (Exim 4.71) (envelope-from ) id 1XlFZc-0005IH-8T for qemu-devel@nongnu.org; Mon, 03 Nov 2014 06:13:33 -0500 Received: from mx1.redhat.com ([209.132.183.28]:56921) by eggs.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1XlFZc-0005IA-0S for qemu-devel@nongnu.org; Mon, 03 Nov 2014 06:13:24 -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 sA3BDND3030848 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-GCM-SHA384 bits=256 verify=FAIL) for ; Mon, 3 Nov 2014 06:13:23 -0500 Date: Mon, 3 Nov 2014 12:13:19 +0100 From: Kevin Wolf Message-ID: <20141103111319.GD4437@noname.str.redhat.com> References: <1414512220-19058-1-git-send-email-armbru@redhat.com> <1414512220-19058-3-git-send-email-armbru@redhat.com> <20141029101242.GA3719@noname.str.redhat.com> <877fzjc76v.fsf@blackfin.pond.sub.org> <20141030093040.GA9097@noname.str.redhat.com> <87oastzprh.fsf@blackfin.pond.sub.org> <5454110E.70809@redhat.com> MIME-Version: 1.0 Content-Type: multipart/signed; micalg=pgp-sha1; protocol="application/pgp-signature"; boundary="sdtB3X0nJg68CQEu" Content-Disposition: inline In-Reply-To: <5454110E.70809@redhat.com> Subject: Re: [Qemu-devel] [PATCH RFC 2/2] block: Warn on insecure format probing List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , To: Eric Blake Cc: jcody@redhat.com, Markus Armbruster , stefanha@redhat.com, qemu-devel@nongnu.org --sdtB3X0nJg68CQEu Content-Type: text/plain; charset=us-ascii Content-Disposition: inline Content-Transfer-Encoding: quoted-printable Am 31.10.2014 um 23:45 hat Eric Blake geschrieben: > On 10/30/2014 06:49 AM, Markus Armbruster wrote: >=20 > > You either have to prevent *any* writing of the first 2048 bytes (the > > part that can be examined by a bdrv_probe() method, or your have to > > prevent writing anything a probe recognizes, or the user has to specify > > the format explicitly. > >=20 > > If you do the former, you're way outside the realm of "theoretical". > >=20 > > If you do the latter, the degree of "theoreticalness" depends on the > > union of the patterns you prevent. Issues: > >=20 > > 1. Anthony's method of checking a few known signatures is fragile. The > > only obviously robust way to test "is probing going to find something > > other than 'raw'?" is running the probes. Feasible. > >=20 > > 2. Whether the union of patterns qualifies as "theoretical" for all our > > targets is not obvious, and whether it'll remain "theoretical" for all > > future formats and target machines even less. >=20 > This one scares me. The proof of concept patch you posted tests whether > a write to the first sector would result in the sector matching a > _currently known probe_ for the file formats that were compiled in at > configure time to the currently running binary. But this is NOT the set > of all possible binary formats that may be introduced in the future. By > extrapolation, if we pursue write blocking, then the only SAFE way to is > to reject ALL writes to the first sector, because we can't know which > writes will match some theoretical future probe - but by the time you > get to that point, then we no longer match bare metal (rejecting ALL > writes to the first sector is ridiculous). There is no absolute security without forbidding raw. Who says that the next format doesn't have its magic in sector 42? You are right that if an attacker knows which new format supporting backing files we'll have in the next version, and the user uses probed raw despite the warning (which means they are not using libvirt), the attacker can write the header of the new image format now and hope that the user leaves it alone until the update happens at some point in the future. Then the malicious guest can access that one file, but not obtain access to the next one (because the new checks are in place then). I don't think this is a relevant attack vector. It's probably much easier to get the user to run an untrusted image than converting a trusted image into a time bomb and waiting potentially for months or years for it to explode. Kevin --sdtB3X0nJg68CQEu Content-Type: application/pgp-signature -----BEGIN PGP SIGNATURE----- Version: GnuPG v2.0.22 (GNU/Linux) iQIcBAEBAgAGBQJUV2NPAAoJEH8JsnLIjy/WA+0P/1Ey8YbpaKd+QIsUwA8pZN4q bSjlRzOJAK1IKilv0cWR9PoPyn/2raO8uEGwyqWPLFJ5GquFwG0gfibLHhtxhYS6 RO9zB3+43cMM8MGM6nzgtBJx/wRW4pS2Lb3A14jD+MrAe/1kM6fe51Y4EQMIfSqy DqaotLJODMeihSlFTI9oTTPepKOvWVcXKfSZpg0ANU9VaavQYwg3SWiZDb52AEaG PBEaARiO/PeVzhZ9VQHFxP7cSe430hF41TARzllFuSWjD63gKK6Dg5NDY4AvVl1/ VZmQiQLw7he8UjZfAnDB0gAS8gxPGGve6ZRDPuIoMqihacruiN23EOdqU3GNlvzD 2eh4q3t8x58rlXnuyRPpuVm88bpSByGFvmgLBrRrfhtTfh1OXkU2AWSLj2pvqnKz y7rzhB6JCyF0uw3zQ455EFZCRdnLVyi78yAo02jEkUcMfQ0Jc3/zIMS6d2UfSuzk TKOMTrojjqAoIC6AHORxebj0Vzm/UBtY2Jxk8bX03W+L8uQruqjz7CGDQ3IxQpi/ ebh+jf56ixqog0sH0Qnmb+sO7aziN2Z08RB19Uwr/jxhGXzc0cOenXZpI8lCIc2o wlkqS/J/XE+sVM6ETLGCjhtL2dkgBV4bpqXI+tGrAS0IOst69YAY2RzfpqvGy4Ee hqRzxXaBHWTM+0z1pRZv =zZwu -----END PGP SIGNATURE----- --sdtB3X0nJg68CQEu--