From mboxrd@z Thu Jan 1 00:00:00 1970 From: "Daniel P. Berrange" Subject: Re: [PATCH]ioemu:fix up error when using qemu-img-xen to create img Date: Tue, 5 May 2009 15:28:23 +0100 Message-ID: <20090505142823.GA12530@redhat.com> References: <10C63FAD690C13458F0B32BCED571F1412A2344B@pdsmsx502.ccr.corp.intel.com> <18936.29628.474866.270018@mariner.uk.xensource.com> <18938.49959.734396.339825@mariner.uk.xensource.com> <18944.19070.403451.993996@mariner.uk.xensource.com> Reply-To: "Daniel P. Berrange" Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Return-path: Content-Disposition: inline In-Reply-To: <18944.19070.403451.993996@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: "Xu, Dongxiao" , "xen-devel@lists.xensource.com" , "Li, Xin" , "Zhang, Yang" List-Id: xen-devel@lists.xenproject.org On Tue, May 05, 2009 at 03:17:34PM +0100, Ian Jackson wrote: > > Consider a raw disk image file which is writeable by a guest. (This > is of course one very common usage model.) The guest can write > anything it likes to the image file, including anything to the start > of the file - where the cow header would be if it were a cow file. > > So it can, if it likes, write a cow header (qcow2 for example) to the > start of its `virtual disk image'. Qemu's cow headers contain the > pathname of the backing file, and the guest can of course name any > file it likes. > > If this image, which is supposedly a raw image, is then opened by any > tool which autoguesses the format, that tool will then spot the cow > header written by the guest and access the backing file (in the > context of the host) specified by the guest. > > Depending on the exact circumstances this can allow the guest to get > copies of or even complete read access to any data of its choice in > the host. > > Upstream qemu have fixed this problem in a half-hearted way and > evidently their qemu-img is still vulnerable. We have changed the > format-determination code in block.c so that any attempt to autodetect > a format never returns `raw'; that means that any vulnerable code > anywhere is instantly fixed although it may break some existing usages > in cases where we haven't properly plumbed through a specification of > the image format. Wasn't the upstream change to add a '-F baseimage_format' enough to allow the flaw to be avoided when creating new images ? Or are you attempting to prevent the issue, even when -F is not used ? Daniel -- |: Red Hat, Engineering, London -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 :|