Date: Mon, 06 Apr 2015 12:52:43 -0700 From: Andy Lutomirski <luto@...nel.org> To: oss-security@...ts.openwall.com, jann@...jh.net CC: cve-assign@...re.org Subject: Re: Linux namespaces: It is possible to escape from bind mounts On 04/04/2015 11:54 AM, cve-assign-AZamIotjMK3YtjvyW6yDsg@...lic.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
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