[oss-security] Linux namespaces: It is possible to escape from bind mounts

[Jann Horn]

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.

[c***@mitre.org]

Post by Jann Horn
http://permalink.gmane.org/gmane.linux.kernel.containers/29173
http://permalink.gmane.org/gmane.linux.kernel.containers/29177
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
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.

Our understanding so far is that the underlying problem is that the
original design didn't fully consider the ability of an attacker to
rename. Because of this, the rename implementation has been changed so
that it detects a violation of the intended security properties and
puts a countermeasure in place. This has been done in the fs/dcache.c
__d_move function. There is no commit available yet at

http://git.kernel.org/cgit/linux/kernel/git/torvalds/linux.git/log/fs/dcache.c

Use CVE-2015-2925 for this issue.

As far as we can tell, the patches don't address a separate scenario
in which a ".." attack can occur but the underlying problem is
something other than rename handling. So, we don't think a second CVE
ID is needed.

(For purposes of CVE, a set of "possible to escape from bind mounts"
discoveries could have multiple IDs if the root cause of one issue
were the acceptability of the ".." syntax in a certain context, and
the root cause of another issue were unrelated to this.)

- --
CVE assignment team, MITRE CVE Numbering Authority
M/S M300
202 Burlington Road, Bedford, MA 01730 USA
[ PGP key available through http://cve.mitre.org/cve/request_id.html ]

[Andy Lutomirski]

On 04/04/2015 11:54 AM,

-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1

Post by Jann Horn
http://permalink.gmane.org/gmane.linux.kernel.containers/29173
http://permalink.gmane.org/gmane.linux.kernel.containers/29177
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
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.

Our understanding so far is that the underlying problem is that the
original design didn't fully consider the ability of an attacker to
rename. Because of this, the rename implementation has been changed so
that it detects a violation of the intended security properties and
puts a countermeasure in place. This has been done in the fs/dcache.c
__d_move function. There is no commit available yet at
http://git.kernel.org/cgit/linux/kernel/git/torvalds/linux.git/log/fs/dcache.c
Use CVE-2015-2925 for this issue.
As far as we can tell, the patches don't address a separate scenario
in which a ".." attack can occur but the underlying problem is
something other than rename handling. So, we don't think a second CVE
ID is needed.

Do you have a specific scenario in mind?

--Andy

[c***@mitre.org]

Post by Andy Lutomirski
Do you have a specific scenario in mind?

We think your question is based on a misinterpretation of what we
wrote. To avoid that, we shouldn't have started a sentence with "As
far as we can tell, the patches don't address."

Post by Andy Lutomirski
As far as we can tell, the patches don't address a separate scenario
in which a ".." attack can occur but the underlying problem is
something other than rename handling. So, we don't think a second CVE
ID is needed.

wasn't intended to mean:

The patches are inadequate because a separate scenario exists,
and that separate scenario is not addressed by the patches.

Instead, it was intended to mean:

We are not disputing that the patches are adequate. Also, in our
current understanding, all attack scenarios ultimately depend on the
previously incorrect handling of renames. Because there isn't a
second type of scenario, there isn't a second CVE ID.

- --
CVE assignment team, MITRE CVE Numbering Authority
M/S M300
202 Burlington Road, Bedford, MA 01730 USA
[ PGP key available through http://cve.mitre.org/cve/request_id.html ]

[Jann Horn]

Post by Jann Horn
<http://permalink.gmane.org/gmane.linux.kernel.containers/29173>
<http://permalink.gmane.org/gmane.linux.kernel.containers/29177>

Which apparently haven't landed in the kernel? The last commit
mentioning bind mounts I could find is 8f502d5b9e336297, which says:

The issue of being able to escape a bind mount has not yet been
addressed, as the fixes are not yet mature"

And the public security issue trackers of Debian, Ubuntu and Redhat
also say that the issue hasn't been fixed:

https://access.redhat.com/security/cve/CVE-2015-2925
https://bugs.launchpad.net/ubuntu/+source/linux/+bug/1441108
https://bugzilla.redhat.com/show_bug.cgi?id=CVE-2015-2925

Post by Jann Horn
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
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.

This issue now is nearly 5 months old. :/

[Solar Designer]

Post by Jann Horn
<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
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