From mboxrd@z Thu Jan 1 00:00:00 1970 Received: from [140.186.70.92] (port=52288 helo=eggs.gnu.org) by lists.gnu.org with esmtp (Exim 4.43) id 1OZO49-0002E4-Q6 for qemu-devel@nongnu.org; Thu, 15 Jul 2010 09:01:35 -0400 Received: from Debian-exim by eggs.gnu.org with spam-scanned (Exim 4.69) (envelope-from ) id 1OZO40-0005gK-Cf for qemu-devel@nongnu.org; Thu, 15 Jul 2010 09:01:28 -0400 Received: from mx1.redhat.com ([209.132.183.28]:52265) by eggs.gnu.org with esmtp (Exim 4.69) (envelope-from ) id 1OZO40-0005g9-3z for qemu-devel@nongnu.org; Thu, 15 Jul 2010 09:01:20 -0400 Message-ID: <4C3F069A.8090609@redhat.com> Date: Thu, 15 Jul 2010 15:01:14 +0200 From: Kevin Wolf MIME-Version: 1.0 References: <1279198257-23681-1-git-send-email-aliguori@us.ibm.com> In-Reply-To: <1279198257-23681-1-git-send-email-aliguori@us.ibm.com> Content-Type: text/plain; charset=ISO-8859-15 Content-Transfer-Encoding: 7bit Subject: [Qemu-devel] Re: [PATCH] Make default invocation of block drivers safer (v3) List-Id: qemu-devel.nongnu.org List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , To: Anthony Liguori Cc: qemu-devel@nongnu.org, Stefan Hajnoczi Am 15.07.2010 14:50, schrieb Anthony Liguori: > CVE-2008-2004 described a vulnerability in QEMU whereas a malicious user could > trick the block probing code into accessing arbitrary files in a guest. To > mitigate this, we added an explicit format parameter to -drive which disabling > block probing. > > Fast forward to today, and the vast majority of users do not use this parameter. > libvirt does not use this by default nor does virt-manager. > > Most users want block probing so we should try to make it safer. > > This patch adds some logic to the raw device which attempts to detect a write > operation to the beginning of a raw device. If the first 4 bytes happen to > match an image file that has a backing file that we support, it scrubs the > signature to all zeros. If a user specifies an explicit format parameter, this > behavior is disabled. > > I contend that while a legitimate guest could write such a signature to the > header, we would behave incorrectly anyway upon the next invocation of QEMU. > This simply changes the incorrect behavior to not involve a security > vulnerability. > > I've tested this pretty extensively both in the positive and negative case. I'm > not 100% confident in the block layer's ability to deal with zero sized writes > particularly with respect to the aio functions so some additional eyes would be > appreciated. > > Even in the case of a single sector write, we have to make sure to invoked the > completion from a bottom half so just removing the zero sized write is not an > option. > > Signed-off-by: Anthony Liguori Acked-by: Kevin Wolf