[<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
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.
