[<prev] [next>] [thread-next>] [day] [month] [year] [list]
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.
Confused about mailing lists and their use?
Read about mailing lists on Wikipedia
and check out these
guidelines on proper formatting of your messages.
