From mboxrd@z Thu Jan 1 00:00:00 1970 Received: from eggs.gnu.org ([2001:4830:134:3::10]:51365) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1XlbPw-0002JE-Ic for qemu-devel@nongnu.org; Tue, 04 Nov 2014 05:32:58 -0500 Received: from Debian-exim by eggs.gnu.org with spam-scanned (Exim 4.71) (envelope-from ) id 1XlbPq-0007dW-Bh for qemu-devel@nongnu.org; Tue, 04 Nov 2014 05:32:52 -0500 Received: from mx1.redhat.com ([209.132.183.28]:33401) by eggs.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1XlbPq-0007dO-4D for qemu-devel@nongnu.org; Tue, 04 Nov 2014 05:32:46 -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 sA4AWiPw031462 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-GCM-SHA384 bits=256 verify=FAIL) for ; Tue, 4 Nov 2014 05:32:45 -0500 Date: Tue, 4 Nov 2014 11:32:42 +0100 From: Kevin Wolf Message-ID: <20141104103242.GC4119@noname.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> <20141103111319.GD4437@noname.str.redhat.com> <87mw87l335.fsf@blackfin.pond.sub.org> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <87mw87l335.fsf@blackfin.pond.sub.org> 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: Markus Armbruster Cc: jcody@redhat.com, qemu-devel@nongnu.org, stefanha@redhat.com Am 04.11.2014 um 10:36 hat Markus Armbruster geschrieben: > Kevin Wolf writes: > > > Am 31.10.2014 um 23:45 hat Eric Blake geschrieben: > >> On 10/30/2014 06:49 AM, Markus Armbruster wrote: > >> > >> > 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. > >> > > >> > If you do the former, you're way outside the realm of "theoretical". > >> > > >> > If you do the latter, the degree of "theoreticalness" depends on the > >> > union of the patterns you prevent. Issues: > >> > > >> > 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. > >> > > >> > 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. > >> > >> 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? > > Correct. > > > 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. > > The threat from using untrusted images with embedded filenames is real. > > Regardless, I wouldn't discount the (different) threat from guests > exploiting "future" probes so cavalierly. If your host is running a > stable distro, its future is easy to know. Even the point of time when > it gets upgraded can be predictable. > > In general, I recommend against leaving security holes in place just > because you think nobody could be bothered to exploit them :) > > Security is not an absolute that cannot be trumped by any other > consideration. I'm perfectly happy to consider usability and > compatibility issues, as well as implementation complexity. I'm much > less willing to accept a "come on, nobody is going to try *that*" > argument. No, I didn't mean to make a "come on, nobody is going to try *that*" argument. I just can think of more attacks that we won't avoid with either approach. For example, what if another program on the host is exploitable and you just need a file with the right content to attack it? A raw image gives you what you need. Nobody is going to try *that* then, if you're content with allowing this? The only full solution is forbidding raw. We have already agreed that this isn't an option. Now we have to draw a line somewhere. Kevin