QEMU "drive_init()" Disk Format Security Bypass

QEMU "drive_init()" Disk Format Security Bypass

[Eren Türkay]

Hello,

An advisory about $subject was released today by secunia. The security flaw 
was fixed in QEmu SVN repository.

Kvm uses some of the old version of qemu that I can't backport patch I grabbed 
from qemu svn repository. Could you look at this issue and provide a patch?

http://secunia.com/advisories/30111/

Svn commit: 
http://svn.savannah.gnu.org/viewvc/?view=rev&root=qemu&revision=4277

Discussion: http://lists.gnu.org/archive/html/qemu-devel/2008-04/msg00675.html

Regards,
Eren

-------------------------------------------------------------------------
This SF.net email is sponsored by the 2008 JavaOne(SM) Conference 
Don't miss this year's exciting event. There's still time to save $100. 
Use priority code J8TL2D2. 
http://ad.doubleclick.net/clk;198757673;13503038;p?http://java.sun.com/javaone

Re: QEMU "drive_init()" Disk Format Security Bypass

[Daniel P. Berrange]

On Thu, May 08, 2008 at 05:02:28PM +0300, Eren T?rkay wrote:
> Hello,
> 
> An advisory about $subject was released today by secunia. The security flaw 
> was fixed in QEmu SVN repository.
> 
> Kvm uses some of the old version of qemu that I can't backport patch I grabbed 
> from qemu svn repository. Could you look at this issue and provide a patch?

KVM is synced to latest CVS version of QEMU on a regular basis.

> http://secunia.com/advisories/30111/
> 
> Svn commit: 
> http://svn.savannah.gnu.org/viewvc/?view=rev&root=qemu&revision=4277

If you look at the KVM userspace code you'll see this patch is already
included:

http://git.kernel.org/?p=virt/kvm/kvm-userspace.git;a=commit;h=ce486fc1116eb53d40635be926bfa147ad520908

Regards,
Daniel
-- 
|: 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 :|

-------------------------------------------------------------------------
This SF.net email is sponsored by the 2008 JavaOne(SM) Conference 
Don't miss this year's exciting event. There's still time to save $100. 
Use priority code J8TL2D2. 
http://ad.doubleclick.net/clk;198757673;13503038;p?http://java.sun.com/javaone

Re: QEMU "drive_init()" Disk Format Security Bypass

[Eren Türkay]

On 08 May 2008 Thu 17:12:14 Daniel P. Berrange wrote:
> If you look at the KVM userspace code you'll see this patch is already
> included:
>
> http://git.kernel.org/?p=virt/kvm/kvm-userspace.git;a=commit;h=ce486fc1116e
>b53d40635be926bfa147ad520908

Thank you, I'll grab the patch and apply it to tarball.

> Regards,
> Daniel

Regards,
Eren

-------------------------------------------------------------------------
This SF.net email is sponsored by the 2008 JavaOne(SM) Conference 
Don't miss this year's exciting event. There's still time to save $100. 
Use priority code J8TL2D2. 
http://ad.doubleclick.net/clk;198757673;13503038;p?http://java.sun.com/javaone

QEMU "drive_init()" Disk Format Security Bypass

[Eren Türkay]

Hello,

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.

Could someone look at this issue and shed a light? If Xen is effected, I would 
really appreciate a patch.

[0] http://secunia.com/advisories/30111/

My best regards,
Eren

Re: QEMU "drive_init()" Disk Format Security Bypass

[Ian Jackson]

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.

Re: QEMU "drive_init()" Disk Format Security Bypass

[Eren Türkay]

On 08 May 2008 Thu 19:58:04 Ian Jackson wrote:
> 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.

Thank you for reply.

Should I file a bug about this situation? I'm looking forward to security fix. 
Btw, KVM also fixed this vulnerability (they just pulled latest qemu code).

Re: QEMU "drive_init()" Disk Format Security Bypass

[Daniel P. Berrange]

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 :|

Re: QEMU "drive_init()" Disk Format Security Bypass

[Keir Fraser]

On 8/5/08 18:12, "Daniel P. Berrange" <berrange@redhat.com> wrote:

>> 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.

Yes, I think we should keep the existing syntax's existing semantics. Just
as qemu/kvm have done.

 -- Keir

Re: QEMU "drive_init()" Disk Format Security Bypass

[Ian Jackson]

Daniel P. Berrange writes ("Re: [Xen-devel] QEMU "drive_init()" Disk Format Security Bypass"):
> 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.

Yes, encoding the format explicit is definitely the way forward.

The question is what to do for existing deployments.  Would the users
prefer to have their system break now or to get rooted in a month or
two ?

Ian.

Re: QEMU "drive_init()" Disk Format Security Bypass

[Daniel P. Berrange]

On Thu, May 08, 2008 at 06:19:30PM +0100, Ian Jackson wrote:
> Daniel P. Berrange writes ("Re: [Xen-devel] QEMU "drive_init()" Disk Format Security Bypass"):
> > 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.
> 
> Yes, encoding the format explicit is definitely the way forward.
> 
> The question is what to do for existing deployments.  Would the users
> prefer to have their system break now or to get rooted in a month or
> two ?

Then disable all format guessing with file: for HVM guests and make it
only use RAW format - this matches semantics of file: with PV guests.
And let them use tap:XXX: if they want QCow with HVM

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 :|

Re: QEMU "drive_init()" Disk Format Security Bypass

[Ian Jackson]

Daniel P. Berrange writes ("Re: [Xen-devel] QEMU "drive_init()" Disk Format Security Bypass"):
> Then disable all format guessing with file: for HVM guests and make it
> only use RAW format - this matches semantics of file: with PV guests.
> And let them use tap:XXX: if they want QCow with HVM

If most people who use file: with HVM are using raw images, then that
is I think the best an interpretation for existing configs.  Users who
want non-blktap cow can say  file:qcow:/path/to/image

Ian.

Re: QEMU "drive_init()" Disk Format Security Bypass

[Daniel P. Berrange]

On Thu, May 08, 2008 at 06:27:10PM +0100, Ian Jackson wrote:
> Daniel P. Berrange writes ("Re: [Xen-devel] QEMU "drive_init()" Disk Format Security Bypass"):
> > Then disable all format guessing with file: for HVM guests and make it
> > only use RAW format - this matches semantics of file: with PV guests.
> > And let them use tap:XXX: if they want QCow with HVM
> 
> If most people who use file: with HVM are using raw images, then that
> is I think the best an interpretation for existing configs.  Users who
> want non-blktap cow can say  file:qcow:/path/to/image

No, that's changing the semantics of file:  That should be done with separate
syntax like tap:qcow:.  There are too many tools which see a disk config
file  file:/path/to/image and expect that everything after the leading
'file:' is the real path. Adding a further qcow: will break those tools.

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 :|