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.
_______________________________________________
Mailing list: https://launchpad.net/~openstack
Post to : openstack@lists.launchpad.net
Unsubscribe : https://launchpad.net/~openstack
More help : https://help.launchpad.net/ListHelp
