openstack team mailing list archive

[Pádraig Brady <P@xxxxxxxxxxxxxx>]

On 08/08/2012 01:00 AM, Michael Still wrote:
> On 08/08/12 07:38, 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.
> 
> I am in the process of re-writing the config drive code as we speak. The
> re-write supports (and defaults to) providing the config drive as an
> iso9660 image.
> 
> There are two places that mounting occurs with the new code:
> 
>  - if the user wants a vfat config drive, as I couldn't find a way to
> create a vfat filesystem from a directory using userspace code. This
> should be "relatively safe" though because the filesystem which is
> mounted is created by the code just before the mount. [1]

That should be very safe.
Note you can change vfat file systems from user space like:

$ truncate -s10M fat.img
$ mkfs.vfat fat.img
$ mmd -i fat.img /etc
$ mtools # Gives a command list

$ mdir -i fat.img
 Volume in drive : has no label
 Volume Serial Number is 8994-9F2E
Directory for ::/

etc          <DIR>     2012-08-08   1:59  etc
        1 file                    0 bytes
                         10 444 800 bytes free

I wouldn't jump through those hoops though,
if we're creating the fat image ourselves.

> 
>  - if the user specifies an image from glance for the injection to occur
> to. This is almost certainly functionality that you're not going to like
> for the reasons stated above. Its there because v1 did it, and I'm
> willing to remove it if there is a consensus that's the right thing to
> do. However, file IO on this image mount is done as the nova user, not
> root, so that's a tiny bit safer (I hope).

If supporting either of the above cases, it would be great to
reuse the existing image loopback mounting code:

virt.disk.setup_container(image_file)
virt.disk.inject_file()
other tweaks
virt.disk.destroy_container(image_file)

> https://review.openstack.org/#/c/10934/

cheers,
Pádraig.