Open Stack

On Tue, 2012-08-07 at 17:38 -0400, Eric Windisch wrote:
> > Pádraig Brady from Red Hat discovered that the fix implemented for
> > CVE-2012-3361 (OSSA-2012-008) was not covering all attack scenarios. By
> > crafting a malicious image with root-readable-only symlinks and
> > requesting a server based on it, an authenticated user could still
> > corrupt arbitrary files (all setups affected) or inject arbitrary files
> > (Essex and later setups with OpenStack API enabled and a libvirt-based
> > hypervisor) on the host filesystem, potentially resulting in full
> > compromise of that compute node.
> >  
> 
> Unfortunately, this won't be the end of vulnerabilities coming from
> this "feature".
> 
> Even if all the edge-cases around safely writing files are handled (and
> I'm not sure they are), simply mounting a filesystem is a very
> dangerous operation for the host.
> 
> The idea had been suggested early-on to supporting ISO9660 filesystems
> created with mkisofs, which can be created in userspace, are read-only,
> and fairly safe to produce, even as root on compute host.
> 
> That idea was apparently shot-down because, "the people who
> documented/requested the blueprint requested a read-write filesystem
> that you cannot obtain with ISO9660".  Now, everyone has to live with a
> serious technical blunder.

Why do we ever read a filesystem touched by a guest in the host?

I think the first step is to make sure that a filesystem that the guest
touched never gets used by the host again, not doing so is just way to
much of a security risk.

Second there are lots of options to create filesystem entirely in
userspace with contents that can later be written to:

 - mformat for vfat
 - growisofs or others for udf
 - genext2fs for ext2
 - e2tools to copy files into an ext2/ext3 filesystem previously created
   by mke2fs

Especially udf is a very interesting options as just about any modern
operating system supports it.  The same is true for vfat, but vfat is
fairly limiting for many use cases.