[<prev] [next>] [<thread-prev] [day] [month] [year] [list]
Message-ID: <20150612192748.GA13099@openwall.com>
Date: Fri, 12 Jun 2015 22:27:48 +0300
From: Solar Designer <solar@...nwall.com>
To: oss-security@...ts.openwall.com
Cc: Jann Horn <jann@...jh.net>
Subject: Re: Linux namespaces: It is possible to escape from bind mounts
On Fri, Apr 03, 2015 at 12:58:02PM +0200, Jann Horn wrote:
> See here for the corresponding patches:
> <http://permalink.gmane.org/gmane.linux.kernel.containers/29173>
> <http://permalink.gmane.org/gmane.linux.kernel.containers/29177>
>
> Given that it went over a public mailinglist now, I guess there's
> not much sense in keeping it secret anymore.
>
> Containers on Linux normally use bind mounts to restrict how much
> of the filesystem is visible for processes inside the container.
> However, if an attacker can gain capabilities within such a
> container or can create another user and mount namespace within
> the existing container, he can do something similar to a
> double-chroot attack to break out of the bind mount and gain
> access to the full filesystem to which the bind mount refers:
>
> Create folders /A, /A/B, /C, /D inside the namespace.
> Bind-mount the /A inside the namespace to /D.
> Let a process chdir to /D/B.
> Move /D/B over into /C.
> The process which chdir'ed to /D/B is now in /C/B, but at the
> same time it is in a bind mount with /D as root. It can then
> traverse upwards, past what looks like / inside the namespace.
I had Jann's message flagged as needing further attention, but I never
got back far enough in my stack of e-mails. Luckily, Jann was
persistent enough and tested OpenVZ for this issue, and found it
vulnerable, and reported the issue to OpenVZ developers. Thanks!
So, yes, OpenVZ simfs-based (but not ploop-based) containers turned out
to be affected by this issue, allowing an in-container root to access
outside files up to the mount point of the underlying filesystem (so
e.g. up to /vz if a separate filesystem is mounted on /vz on a server).
With proper bind mount(s) already precreated, a non-root in-container
user could exploit this as well, but that's uncommon.
OpenVZ bug:
https://bugzilla.openvz.org/show_bug.cgi?id=3256
OpenVZ/RHEL6 fix:
https://openvz.org/Download/kernel/rhel6-testing/042stab108.3
OpenVZ/RHEL5 fix:
https://openvz.org/Download/kernel/rhel5-testing/028stab119.2
(And a fix went into Owl last night.)
A slightly simpler variation of the attack, without a "d" directory:
cd /
mkdir a a/b c
mount -o bind a c
cd c/b
mv /a/b /
ls -l ../../../../../..
Alexander
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.
