Date: Wed, 18 Jun 2014 09:36:28 +0200 From: Sebastian Krahmer <krahmer@...e.de> To: oss-security@...ts.openwall.com Subject: docker VMM breakout Hi As per list policy, here is the public forward. The link has been redacted to reflect public location. Its fixed in docker 1.0 since CAP_DAC_READ_SEARCH is no longer available. Other FS-related threats to container based VMM's that have been discussed: - subvolume related FS operations (snapshots etc) - FS ioctl's that accept FS-handles as well (XFS) - CAP_DAC_READ_SEARCH also defeats chroot and other bind-mount containers (privileged LXC) - CAP_MKNOD might be a problem too (still available in docker 1.0) depending on the drivers available in the kernel ----- Forwarded message from Sebastian Krahmer ----- Subject: [vs] docker VMM breakout Date: Mon, 16 Jun 2014 10:56:16 +0200 Hi I dont know if this really belongs here, but better safe than sorry. There seem to be distributors that actually ship docker as a 'solution' (to whatever problem :). I already contacted upstream, they say its not working anymore for them in version 1.0. I cannot test this, as I only have docker 0.11 running (on a 3.11 kernel). I am not really sure they really fixed the problem, they just told me that they changed "something" in the capability handling. In 0.11 the problem is that the apps that run in the container have CAP_DAC_READ_SEARCH and CAP_DAC_OVERRIDE which allows the containered app to access files not just by pathname (which would be impossible due to the bind mount of the rootfs) but also by handles via open_by_handle_at(). Handles are mostly 64bit values and can be kind of pre-computed as they are inode-based and the inode of / is 2. So you can go ahead and walk / by passing a handle of 2 and search the FS until you find the inode# of the file you want to access. Even though you are containered somewhere in /var/lib. A PoC is available here: http://stealth.openwall.net/xSports/shocker.c Note that some FS (namely XFS) have their own fhandle ioctls, so if you share the XFS fs structs with the container, there might be different attack vectors despite of capability handling. Since docker is heavily LXC based, any other LXC based container solution might be at risk too. (I think file handles are a generic problem for container based VMMs). I request a CRD of June 30th. If within the next 2 days no other distributor objects, I will already disclose this on June 18th, because the overall issue is not really a critical thing. Sebastian -- ~ perl self.pl ~ $_='print"\$_=\47$_\47;eval"';eval ~ krahmer@...e.de - SuSE Security Team ----- End forwarded message ----- -- ~ perl self.pl ~ $_='print"\$_=\47$_\47;eval"';eval ~ krahmer@...e.de - SuSE Security Team
Powered by blists - more mailing lists
Please check out the Open Source Software Security Wiki, which is counterpart to this mailing list.
Powered by Openwall GNU/*/Linux - Powered by OpenVZ