Xen 
 
Home About Xen.org Xen Xen Summit Wiki Mailing List Bug Tracker Xen Downloads
 
   
 

xen-devel

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

To: Eren Türkay <turkay.eren@xxxxxxxxx>
Subject: Re: [Xen-devel] QEMU "drive_init()" Disk Format Security Bypass
From: Ian Jackson <Ian.Jackson@xxxxxxxxxxxxx>
Date: Thu, 8 May 2008 17:58:04 +0100
Cc: xen-devel@xxxxxxxxxxxxxxxxxxx
Delivery-date: Thu, 08 May 2008 09:58:55 -0700
Envelope-to: www-data@xxxxxxxxxxxxxxxxxx
In-reply-to: <200805081800.24064.turkay.eren@xxxxxxxxx>
List-help: <mailto:xen-devel-request@lists.xensource.com?subject=help>
List-id: Xen developer discussion <xen-devel.lists.xensource.com>
List-post: <mailto:xen-devel@lists.xensource.com>
List-subscribe: <http://lists.xensource.com/cgi-bin/mailman/listinfo/xen-devel>, <mailto:xen-devel-request@lists.xensource.com?subject=subscribe>
List-unsubscribe: <http://lists.xensource.com/cgi-bin/mailman/listinfo/xen-devel>, <mailto:xen-devel-request@lists.xensource.com?subject=unsubscribe>
Newsgroups: chiark.mail.xen.devel
References: <200805081800.24064.turkay.eren@xxxxxxxxx>
Sender: xen-devel-bounces@xxxxxxxxxxxxxxxxxxx
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 ?

We can add a safety catch so that if what is supposedly a raw image
looks like a cow disk, we fail, unless the rawness was explicitly
specified.  So we can avoid data corruption although as far as I can
see at the moment we have to at least break some existing
deployments.

Ian.

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