Re: Linux namespaces: It is possible to escape from bind mounts

[Andy Lutomirski <luto () kernel org>]

On 04/04/2015 11:54 AM, 
cve-assign-AZamIotjMK3YtjvyW6yDsg () public gmane org wrote:
> -----BEGIN PGP SIGNED MESSAGE-----
> Hash: SHA1
>
> > 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
> > 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
>
>    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