[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Message-Id: <20150404185434.6F84B6C0048@smtpvmsrv1.mitre.org>
Date: Sat, 4 Apr 2015 14:54:34 -0400 (EDT)
From: cve-assign@...re.org
To: jann@...jh.net
Cc: cve-assign@...re.org, oss-security@...ts.openwall.com
Subject: Re: Linux namespaces: It is possible to escape from bind mounts
-----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.
(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 ]
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.4.14 (SunOS)
iQEcBAEBAgAGBQJVIDIRAAoJEKllVAevmvmsw7YIAJjYr1bQr1YxTISGoFlx40Z3
NE6Y6icrOwqwj2SBhDx2U7i/t5PSIz9bqAL+dsHRKgYumYr5wYHnwBofqkhOsw0u
bXhh3R+5xWVHHhcYgAkIUPr7L4D+jN8qp9IpvM7Z4wpgXwdr2HIpKE8sKdKwvqLR
oaUkqrvZi5QEcW8sWONIi65FJmG2l9YcHQ5wpM7E3wN7HIoFK005er40882mMimC
zJpLiBt1/SMqplGLUCFaMQ64SnC90EBJE3r8rGPWBaDGaS8mW6yRV5h++2t3K4dM
axFwwkOrJcpcrbjGeBowte44XJ/1W2wgq9t/6NXFzuPxmE+JyTa/tv5xF795lLI=
=vO4b
-----END PGP SIGNATURE-----
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.
