Openwall GNU/*/Linux - a small security-enhanced Linux distro for servers
[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
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

Your e-mail address:

Please check out the Open Source Software Security Wiki, which is counterpart to this mailing list.

Powered by Openwall GNU/*/Linux - Powered by OpenVZ