From mboxrd@z Thu Jan 1 00:00:00 1970 From: "Daniel P. Berrange" Subject: Re: QEMU "drive_init()" Disk Format Security Bypass Date: Thu, 8 May 2008 18:12:55 +0100 Message-ID: <20080508171255.GA31908@redhat.com> References: <200805081800.24064.turkay.eren@gmail.com> <18467.12572.126574.502777@mariner.uk.xensource.com> Reply-To: "Daniel P. Berrange" Mime-Version: 1.0 Content-Type: text/plain; charset=iso-8859-1 Content-Transfer-Encoding: quoted-printable Return-path: Content-Disposition: inline In-Reply-To: <18467.12572.126574.502777@mariner.uk.xensource.com> List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Sender: xen-devel-bounces@lists.xensource.com Errors-To: xen-devel-bounces@lists.xensource.com To: Ian Jackson Cc: Eren =?utf-8?Q?T=C3=BCrkay?= , xen-devel@lists.xensource.com List-Id: xen-devel@lists.xenproject.org On Thu, May 08, 2008 at 05:58:04PM +0100, Ian Jackson wrote: > Eren T=FCrkay writes ("[Xen-devel] QEMU "drive_init()" Disk Format > > Security Bypass"): Today, a security flaw in Qemu was released at > > secunia [0] which was fixed in qemu svn repository. > > > > Xen uses part of a qemu code including "vl.c" in which the security > > flaw appeared. I suspect that Xen is effected by this vulnerability > > too but I couldn't find same lines in vl.c and I'm not sure about > > it. >=20 > I've looked into it and I'm afraid that yes, Xen is vulnerable. We > use the same code in qemu, but via a different path. The patch used > to fix the situation in qemu upstream in inapplicable to the current > ioemu. As far as I can see the problem is with HVM guests where a > file which is supposed to be a raw image is specified in the > configuration. >=20 > If the object mentioned in the configuration is a block device all is > well, as qemu forces the format to raw in that case. If the file is > actually a non-raw image format qemu will determine the type > correctly. For PV guests, the tap driver is used instead - although I > haven't checked that for a similar problem. >=20 > There is a problem constructing a proper fix, unfortunately. If you > write file:/path/to/some/file in your configuration, it is > ambiguous: did you mean that /path/to/some/file was a raw disk image > or a cow format with separate backing file ? (The cow formats contain > the filename of the backing file.) >=20 > As far as I can tell there is not currently any way to specify the > format explicitly. qemu-dm always autoguesses. >=20 > Should we break all old installations by requiring everyone to specify > a format ? Or should we break only some old installations by > retaining the current syntax to mean one thing or the other ? Perhaps > we should attempt to guess according to the _filename_, which is > controlled by the host and thus safe. Do users typically choose > filenames for cow images which are enough of a giveaway ? Well, tap:XXX: style URLS already encode the format explicitly. So if we made QEMU understand that syntax too, then that gives admins the=20 option to be secure, while keeping file: fas a legacy (unsecure) mode for compatability. This has the added advantage that it'd be the same syntax used for PV-on-HVM drivers, and avoids nasty guessing based on filename. Dan. --=20 |: Red Hat, Engineering, Boston -o- http://people.redhat.com/berrange= / :| |: http://libvirt.org -o- http://virt-manager.org -o- http://ovirt.or= g :| |: http://autobuild.org -o- http://search.cpan.org/~danberr= / :| |: GnuPG: 7D3B9505 -o- F3C9 553F A1DA 4AC2 5648 23C1 B3DF F742 7D3B 950= 5 :|