Follow @Openwall on Twitter for new release announcements and other news
[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Date: Sat,  4 Apr 2015 14:54:34 -0400 (EDT)
Subject: Re: Linux namespaces: It is possible to escape from bind mounts

Hash: SHA1


> 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.

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

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 ]
Version: GnuPG v1.4.14 (SunOS)


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.