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.
Powered by Openwall GNU/*/Linux - Powered by OpenVZ