[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

Re: [Xen-devel] QEMU "drive_init()" Disk Format Security Bypass



On Thu, May 08, 2008 at 05:58:04PM +0100, Ian Jackson wrote:
> Eren Türkay 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.
> 
> 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.
> 
> 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.
> 
> 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.)
> 
> As far as I can tell there is not currently any way to specify the
> format explicitly.  qemu-dm always autoguesses.
> 
> 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 
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.
-- 
|: Red Hat, Engineering, Boston   -o-   http://people.redhat.com/berrange/ :|
|: http://libvirt.org  -o-  http://virt-manager.org  -o-  http://ovirt.org :|
|: http://autobuild.org       -o-         http://search.cpan.org/~danberr/ :|
|: GnuPG: 7D3B9505  -o-  F3C9 553F A1DA 4AC2 5648 23C1 B3DF F742 7D3B 9505 :|

_______________________________________________
Xen-devel mailing list
Xen-devel@xxxxxxxxxxxxxxxxxxx
http://lists.xensource.com/xen-devel


 


Rackspace

Lists.xenproject.org is hosted with RackSpace, monitoring our
servers 24x7x365 and backed by RackSpace's Fanatical Support®.