[PATCHES] Bind mount escape fixes (CVE-2015-2925)

[PATCHES] Bind mount escape fixes (CVE-2015-2925)

[Eric W. Biederman]

[-- Attachment #1: Type: text/plain, Size: 984 bytes --]


With a strategically placed rename bind mounts can be tricked into
giving processes access to the entire filesystem instead of just a piece
of it.  This misfeature has existed since bind mounts were introduced
into the kernel.  This issue has been fixed in Linus's tree and below
are my tested backports of the fixes to 4.2.1, 4.1.8, 3.18.21, 3.14.53,
3.12.48, 3.10.89, 3.4.109, 3.2.71, 2.6.32.68.  All of the kernels 
currently listed as being active.

The fixes backported are:
cde93be45a8a90d8c264c776fab63487b5038a65 dcache: Handle escaped paths in prepend_path
397d425dc26da728396e66d392d5dcb8dac30c37 vfs: Test for and handle paths that are unreachable from their mnt_root

As I backported the patches the logical work remained the same but the
exact implemenation details changed to fit in with the vfs present in
the older kernels.  Minor changes were needed for every the backport to
every kernel except 4.2.1.

Please queue these changes for the appropriate stable trees.


[-- Attachment #2: bind-4.2.mbox --]
[-- Type: application/mbox, Size: 5682 bytes --]

[-- Attachment #3: bind-4.1.mbox --]
[-- Type: application/mbox, Size: 5980 bytes --]

[-- Attachment #4: bind-3.18.mbox --]
[-- Type: application/mbox, Size: 5982 bytes --]

[-- Attachment #5: bind-3.14.mbox --]
[-- Type: application/mbox, Size: 5982 bytes --]

[-- Attachment #6: bind-3.12.mbox --]
[-- Type: application/mbox, Size: 5945 bytes --]

[-- Attachment #7: bind-3.10.mbox --]
[-- Type: application/mbox, Size: 6020 bytes --]

[-- Attachment #8: bind-3.4.mbox --]
[-- Type: application/mbox, Size: 6032 bytes --]

[-- Attachment #9: bind-3.2.mbox --]
[-- Type: application/mbox, Size: 6003 bytes --]

[-- Attachment #10: bind-2.6.32.mbox --]
[-- Type: application/mbox, Size: 6499 bytes --]

[-- Attachment #11: Type: text/plain, Size: 6 bytes --]


Eric

Re: [PATCHES] Bind mount escape fixes (CVE-2015-2925)

[Willy Tarreau]

[ trimmed CC list ]

On Thu, Oct 01, 2015 at 11:15:47AM -0500, Eric W. Biederman wrote:
> 
> With a strategically placed rename bind mounts can be tricked into
> giving processes access to the entire filesystem instead of just a piece
> of it.  This misfeature has existed since bind mounts were introduced
> into the kernel.  This issue has been fixed in Linus's tree and below
> are my tested backports of the fixes to 4.2.1, 4.1.8, 3.18.21, 3.14.53,
> 3.12.48, 3.10.89, 3.4.109, 3.2.71, 2.6.32.68.  All of the kernels 
> currently listed as being active.
(...)

queued for 2.6.32, much appreciated, thanks Eric!

Willy

Re: [PATCHES] Bind mount escape fixes (CVE-2015-2925)

[Ben Hutchings]

[-- Attachment #1: Type: text/plain, Size: 1900 bytes --]

On Thu, 2015-10-01 at 11:15 -0500, Eric W. Biederman wrote:
> With a strategically placed rename bind mounts can be tricked into
> giving processes access to the entire filesystem instead of just a piece
> of it.  This misfeature has existed since bind mounts were introduced
> into the kernel.  This issue has been fixed in Linus's tree and below
> are my tested backports of the fixes to 4.2.1, 4.1.8, 3.18.21, 3.14.53,
> 3.12.48, 3.10.89, 3.4.109, 3.2.71, 2.6.32.68.  All of the kernels 
> currently listed as being active.

I'm not convinced that this is necessary for the 2.6.32, 3.2 or 3.4
stable branches.  While it is possible for an administrator to screw
this up, there is no possibility of a user being able to exploit this
from a user namespace where they have namespaced-CAP_SYS_ADMIN.

> The fixes backported are:
> cde93be45a8a90d8c264c776fab63487b5038a65 dcache: Handle escaped paths in prepend_path
> 397d425dc26da728396e66d392d5dcb8dac30c37 vfs: Test for and handle paths that are unreachable from their mnt_root

For 3.16 I started with:

70291aecc6aa228c1b3bb36a5f3efdb0af636042 namei: lift (open-coded) terminate_walk() in follow_dotdot_rcu() into callers

which then made the other two trivial to apply.  I think that would
also work for 3.14 and 3.18.

> As I backported the patches the logical work remained the same but the
> exact implemenation details changed to fit in with the vfs present in
> the older kernels.  Minor changes were needed for every the backport to
> every kernel except 4.2.1.
>
> Please queue these changes for the appropriate stable trees.

For 4.2, I had the idea that this one was needed too:

a03e283bf5c3d4851b4998122196ce9f849e6dfb dcache: Reduce the scope of i_lock in d_splice_alias

but perhaps that is just cleanup/optimisation?

Ben.

-- 
Ben Hutchings
When in doubt, use brute force. - Ken Thompson

[-- Attachment #2: This is a digitally signed message part --]
[-- Type: application/pgp-signature, Size: 811 bytes --]

Re: [PATCHES] Bind mount escape fixes (CVE-2015-2925)

[Eric W. Biederman]

Ben Hutchings <ben@decadent.org.uk> writes:

> On Thu, 2015-10-01 at 11:15 -0500, Eric W. Biederman wrote:
>> With a strategically placed rename bind mounts can be tricked into
>> giving processes access to the entire filesystem instead of just a piece
>> of it.  This misfeature has existed since bind mounts were introduced
>> into the kernel.  This issue has been fixed in Linus's tree and below
>> are my tested backports of the fixes to 4.2.1, 4.1.8, 3.18.21, 3.14.53,
>> 3.12.48, 3.10.89, 3.4.109, 3.2.71, 2.6.32.68.  All of the kernels 
>> currently listed as being active.
>
> I'm not convinced that this is necessary for the 2.6.32, 3.2 or 3.4
> stable branches.  While it is possible for an administrator to screw
> this up, there is no possibility of a user being able to exploit this
> from a user namespace where they have namespaced-CAP_SYS_ADMIN.

It is cheap and easy to fix.  I made and tested the changes.  So why
not.

Nothing about the bug or the exploit depends on user namespaces, user
namespaces just make it 100% reliable to arrange the necessary
conditions to be able to escape a bind mount.  I don't think anyone
even knew what to look for to allow or prevent this until just recently.
So I hesitate to call it an administrator messed up if no one understood
the issue existed.

>> The fixes backported are:
>> cde93be45a8a90d8c264c776fab63487b5038a65 dcache: Handle escaped paths in prepend_path
>> 397d425dc26da728396e66d392d5dcb8dac30c37 vfs: Test for and handle paths that are unreachable from their mnt_root
>
> For 3.16 I started with:
>
> 70291aecc6aa228c1b3bb36a5f3efdb0af636042 namei: lift (open-coded) terminate_walk() in follow_dotdot_rcu() into callers
>
> which then made the other two trivial to apply.  I think that would
> also work for 3.14 and 3.18.

It probably does fix the issue.  Without applying
70291aecc6aa228c1b3bb36a5f3efdb0af636042 and reading the code of
fs/namei.c I can not tell.  That would probably take me an hour and I am
not volunteering that time right now.  That backport addresses the
issues I can think of off the top of my head with in for 3.14 and 3.18,
but there are a lot of subtle dependencies in fs/namei.c.

What I know is that there were a number of kernels where my patch that
added a return and a return code to follow_dotdot applied cleanly but
did not work correctly.  mountpoint_last was a factor, as was the
movement/consolidation of terminate_walk().

I found it easier to adapt my change to follow_dotdot to not need
the movement of terminate_walk() than to figure out which part of
the cleanup would be needed to remove the need.

For a backport it seemed the better part of valor to make the necessary
changes as small and as locally correct as I could.  As with less code
it is harder to get it wrong.

>> As I backported the patches the logical work remained the same but the
>> exact implemenation details changed to fit in with the vfs present in
>> the older kernels.  Minor changes were needed for every the backport to
>> every kernel except 4.2.1.
>>
>> Please queue these changes for the appropriate stable trees.
>
> For 4.2, I had the idea that this one was needed too:
>
> a03e283bf5c3d4851b4998122196ce9f849e6dfb dcache: Reduce the scope of i_lock in d_splice_alias
>
> but perhaps that is just cleanup/optimisation?

Yes it has no immediate bearing on this issue as it was fixed.

It is halfway to fixing the locking craziness in d_splice_alias and a
more ambitious fix would probably could take advantage of that.  But
the more ambitious fix was not 

Yes that is just a cleanup.  It is also half way to removing the locking
craziness in d_splice_alias.  Which is a related but different battle.

Eric

Re: [PATCHES] Bind mount escape fixes (CVE-2015-2925)

[Eric W. Biederman]

ebiederm@xmission.com (Eric W. Biederman) writes:

> Ben Hutchings <ben@decadent.org.uk> writes:
>
>> On Thu, 2015-10-01 at 11:15 -0500, Eric W. Biederman wrote:
>>> With a strategically placed rename bind mounts can be tricked into
>>> giving processes access to the entire filesystem instead of just a piece
>>> of it.  This misfeature has existed since bind mounts were introduced
>>> into the kernel.  This issue has been fixed in Linus's tree and below
>>> are my tested backports of the fixes to 4.2.1, 4.1.8, 3.18.21, 3.14.53,
>>> 3.12.48, 3.10.89, 3.4.109, 3.2.71, 2.6.32.68.  All of the kernels 
>>> currently listed as being active.
>>
>> I'm not convinced that this is necessary for the 2.6.32, 3.2 or 3.4
>> stable branches.  While it is possible for an administrator to screw
>> this up, there is no possibility of a user being able to exploit this
>> from a user namespace where they have namespaced-CAP_SYS_ADMIN.
>
> It is cheap and easy to fix.  I made and tested the changes.  So why
> not.
>

Having thought about this I definitely think we need this on older
kernels.  I am aware of at least one piece of software that predates
2.6.32 is vulnerable to this escape.

The software in all innocence bind mounted a users /home directory into
a root filesystem that was stored in the users /home directory.  That
is enough to allow the escape with a simple unprivileged rename.

So since this is actually exploitable on real userspace software that
predates 2.6.32 I think this fix needs to be backported, as it is not
a theoretical issue.

Eric

Re: [PATCHES] Bind mount escape fixes (CVE-2015-2925)

[Ben Hutchings]

[-- Attachment #1: Type: text/plain, Size: 831 bytes --]

On Fri, 2015-10-02 at 11:01 -0500, Eric W. Biederman wrote:
[...]
> Having thought about this I definitely think we need this on older
> kernels.  I am aware of at least one piece of software that predates
> 2.6.32 is vulnerable to this escape.
> 
> The software in all innocence bind mounted a users /home directory into
> a root filesystem that was stored in the users /home directory.  That
> is enough to allow the escape with a simple unprivileged rename.
>
> So since this is actually exploitable on real userspace software that
> predates 2.6.32 I think this fix needs to be backported, as it is not
> a theoretical issue.

Thanks for the explanation.  I'll review and test the patches for
2.6.32 and 3.2 in a while.

Ben.

-- 
Ben Hutchings
compatible: Gracefully accepts erroneous data from any source

[-- Attachment #2: This is a digitally signed message part --]
[-- Type: application/pgp-signature, Size: 811 bytes --]

Re: [PATCHES] Bind mount escape fixes (CVE-2015-2925)

[Willy Tarreau]

On Sat, Oct 03, 2015 at 02:48:03AM +0100, Ben Hutchings wrote:
> On Fri, 2015-10-02 at 11:01 -0500, Eric W. Biederman wrote:
> [...]
> > Having thought about this I definitely think we need this on older
> > kernels.  I am aware of at least one piece of software that predates
> > 2.6.32 is vulnerable to this escape.
> > 
> > The software in all innocence bind mounted a users /home directory into
> > a root filesystem that was stored in the users /home directory.  That
> > is enough to allow the escape with a simple unprivileged rename.
> >
> > So since this is actually exploitable on real userspace software that
> > predates 2.6.32 I think this fix needs to be backported, as it is not
> > a theoretical issue.
> 
> Thanks for the explanation.  I'll review and test the patches for
> 2.6.32 and 3.2 in a while.

Thanks as well.

Willy

Re: [PATCHES] Bind mount escape fixes (CVE-2015-2925)

[Jiri Slaby]

On 10/01/2015, 06:15 PM, Eric W. Biederman wrote:
> 
> With a strategically placed rename bind mounts can be tricked into
> giving processes access to the entire filesystem instead of just a piece
> of it.  This misfeature has existed since bind mounts were introduced
> into the kernel.  This issue has been fixed in Linus's tree and below
> are my tested backports of the fixes to 4.2.1, 4.1.8, 3.18.21, 3.14.53,
> 3.12.48, 3.10.89, 3.4.109, 3.2.71, 2.6.32.68.  All of the kernels 
> currently listed as being active.
> 
> The fixes backported are:
> cde93be45a8a90d8c264c776fab63487b5038a65 dcache: Handle escaped paths in prepend_path
> 397d425dc26da728396e66d392d5dcb8dac30c37 vfs: Test for and handle paths that are unreachable from their mnt_root
> 
> As I backported the patches the logical work remained the same but the
> exact implemenation details changed to fit in with the vfs present in
> the older kernels.  Minor changes were needed for every the backport to
> every kernel except 4.2.1.
> 
> Please queue these changes for the appropriate stable trees.

Applied to 3.12. Thanks!

-- 
js
suse labs

Re: [PATCHES] Bind mount escape fixes (CVE-2015-2925)

[Luis Henriques]

On Thu, Oct 01, 2015 at 11:15:47AM -0500, Eric W. Biederman wrote:
> 
> With a strategically placed rename bind mounts can be tricked into
> giving processes access to the entire filesystem instead of just a piece
> of it.  This misfeature has existed since bind mounts were introduced
> into the kernel.  This issue has been fixed in Linus's tree and below
> are my tested backports of the fixes to 4.2.1, 4.1.8, 3.18.21, 3.14.53,
> 3.12.48, 3.10.89, 3.4.109, 3.2.71, 2.6.32.68.  All of the kernels 
> currently listed as being active.
> 
> The fixes backported are:
> cde93be45a8a90d8c264c776fab63487b5038a65 dcache: Handle escaped paths in prepend_path
> 397d425dc26da728396e66d392d5dcb8dac30c37 vfs: Test for and handle paths that are unreachable from their mnt_root
> 
> As I backported the patches the logical work remained the same but the
> exact implemenation details changed to fit in with the vfs present in
> the older kernels.  Minor changes were needed for every the backport to
> every kernel except 4.2.1.
> 
> Please queue these changes for the appropriate stable trees.
> 

Thank you, Eric.  I'm queuing these for the 3.16 kernel as well (picking
the 3.18 backports).

Cheers,
--
Lu�s

Re: [PATCHES] Bind mount escape fixes (CVE-2015-2925)

[Ben Hutchings]

[-- Attachment #1.1: Type: text/plain, Size: 2807 bytes --]

On Thu, 2015-10-01 at 11:15 -0500, Eric W. Biederman wrote:
> With a strategically placed rename bind mounts can be tricked into
> giving processes access to the entire filesystem instead of just a piece
> of it.  This misfeature has existed since bind mounts were introduced
> into the kernel.  This issue has been fixed in Linus's tree and below
> are my tested backports of the fixes to 4.2.1, 4.1.8, 3.18.21, 3.14.53,
> 3.12.48, 3.10.89, 3.4.109, 3.2.71, 2.6.32.68.  All of the kernels 
> currently listed as being active.
> 
> The fixes backported are:
> cde93be45a8a90d8c264c776fab63487b5038a65 dcache: Handle escaped paths in prepend_path
> 397d425dc26da728396e66d392d5dcb8dac30c37 vfs: Test for and handle paths that are unreachable from their mnt_root
> 
> As I backported the patches the logical work remained the same but the
> exact implemenation details changed to fit in with the vfs present in
> the older kernels.  Minor changes were needed for every the backport to
> every kernel except 4.2.1.
> 
> Please queue these changes for the appropriate stable trees.

For 2.6.32, the first backport looks wrong:

> --- a/fs/dcache.c
> +++ b/fs/dcache.c
> @@ -1910,7 +1910,7 @@ char *__d_path(const struct path *path, struct path *root,
>         struct dentry *dentry = path->dentry;
>         struct vfsmount *vfsmnt = path->mnt;
>         char *end = buffer + buflen;
> -       char *retval;
> +       char *retval, *tail;
>  
>         spin_lock(&vfsmount_lock);
>         prepend(&end, &buflen, "\0", 1);
> @@ -1923,6 +1923,7 @@ char *__d_path(const struct path *path, struct path *root,
>         /* Get '/' right */
>         retval = end-1;
>         *retval = '/';
> +       tail = end;

So tail points to the null terminator.

>         for (;;) {
>                 struct dentry * parent;
> @@ -1930,6 +1931,12 @@ char *__d_path(const struct path *path, struct path *root,
>                 if (dentry == root->dentry && vfsmnt == root->mnt)
>                         break;
>                 if (dentry == vfsmnt->mnt_root || IS_ROOT(dentry)) {
> +                       /* Escaped? */
> +                       if (dentry != vfsmnt->mnt_root) {
> +                               retval = tail;
> +                               *retval = '/';

Now we overwrite the null terminator.

> +                               goto out;
> +                       }
>                         /* Global root? */
>                         if (vfsmnt->mnt_parent == vfsmnt) {
>                                 goto global_root;

Also, nothing inserts the "(unreachable)" string.  I've attached my
version, which deals with both of these.

Ben.

-- 
Ben Hutchings
Once a job is fouled up, anything done to improve it makes it worse.

[-- Attachment #1.2: dcache-handle-escaped-paths-in-prepend_path.patch --]
[-- Type: text/x-patch, Size: 2886 bytes --]

From: "Eric W. Biederman" <ebiederm@xmission.com>
Date: Sat, 15 Aug 2015 13:36:12 -0500
Subject: dcache: Handle escaped paths in prepend_path
Origin: https://git.kernel.org/linus/cde93be45a8a90d8c264c776fab63487b5038a65

A rename can result in a dentry that by walking up d_parent
will never reach it's mnt_root.  For lack of a better term
I call this an escaped path.

prepend_path is called by four different functions __d_path,
d_absolute_path, d_path, and getcwd.

__d_path only wants to see paths are connected to the root it passes
in.  So __d_path needs prepend_path to return an error.

d_absolute_path similarly wants to see paths that are connected to
some root.  Escaped paths are not connected to any mnt_root so
d_absolute_path needs prepend_path to return an error greater
than 1.  So escaped paths will be treated like paths on lazily
unmounted mounts.

getcwd needs to prepend "(unreachable)" so getcwd also needs
prepend_path to return an error.

d_path is the interesting hold out.  d_path just wants to print
something, and does not care about the weird cases.  Which raises
the question what should be printed?

Given that <escaped_path>/<anything> should result in -ENOENT I
believe it is desirable for escaped paths to be printed as empty
paths.  As there are not really any meaninful path components when
considered from the perspective of a mount tree.

So tweak prepend_path to return an empty path with an new error
code of 3 when it encounters an escaped path.

Signed-off-by: "Eric W. Biederman" <ebiederm@xmission.com>
Signed-off-by: Al Viro <viro@zeniv.linux.org.uk>
[bwh: For 2.6.32, implement the "(unreachable)" string in __d_path()]
Signed-off-by: Ben Hutchings <ben@decadent.org.uk>
---
 fs/dcache.c | 9 ++++++++-
 1 file changed, 8 insertions(+), 1 deletion(-)

diff --git a/fs/dcache.c b/fs/dcache.c
index 44c0aeafcbc9..e1accce92f68 100644
--- a/fs/dcache.c
+++ b/fs/dcache.c
@@ -1910,7 +1910,7 @@ char *__d_path(const struct path *path, struct path *root,
 	struct dentry *dentry = path->dentry;
 	struct vfsmount *vfsmnt = path->mnt;
 	char *end = buffer + buflen;
-	char *retval;
+	char *retval, *tail;
 
 	spin_lock(&vfsmount_lock);
 	prepend(&end, &buflen, "\0", 1);
@@ -1923,6 +1923,7 @@ char *__d_path(const struct path *path, struct path *root,
 	/* Get '/' right */
 	retval = end-1;
 	*retval = '/';
+	tail = end;
 
 	for (;;) {
 		struct dentry * parent;
@@ -1930,6 +1931,14 @@ char *__d_path(const struct path *path, struct path *root,
 		if (dentry == root->dentry && vfsmnt == root->mnt)
 			break;
 		if (dentry == vfsmnt->mnt_root || IS_ROOT(dentry)) {
+			/* Escaped? */
+			if (dentry != vfsmnt->mnt_root) {
+				buflen += (tail - end);
+				end = tail;
+				prepend(&end, &buflen, "(unreachable)/", 14);
+				retval = end;
+				goto out;
+			}
 			/* Global root? */
 			if (vfsmnt->mnt_parent == vfsmnt) {
 				goto global_root;

[-- Attachment #2: This is a digitally signed message part --]
[-- Type: application/pgp-signature, Size: 811 bytes --]

Re: [PATCHES] Bind mount escape fixes (CVE-2015-2925)

[Willy Tarreau]

Hi Ben,

On Thu, Oct 08, 2015 at 02:08:28AM +0100, Ben Hutchings wrote:
> For 2.6.32, the first backport looks wrong:
> 
> > --- a/fs/dcache.c
> > +++ b/fs/dcache.c
> > @@ -1910,7 +1910,7 @@ char *__d_path(const struct path *path, struct path *root,
> >         struct dentry *dentry = path->dentry;
> >         struct vfsmount *vfsmnt = path->mnt;
> >         char *end = buffer + buflen;
> > -       char *retval;
> > +       char *retval, *tail;
> >  
> >         spin_lock(&vfsmount_lock);
> >         prepend(&end, &buflen, "\0", 1);
> > @@ -1923,6 +1923,7 @@ char *__d_path(const struct path *path, struct path *root,
> >         /* Get '/' right */
> >         retval = end-1;
> >         *retval = '/';
> > +       tail = end;
> 
> So tail points to the null terminator.
> 
> >         for (;;) {
> >                 struct dentry * parent;
> > @@ -1930,6 +1931,12 @@ char *__d_path(const struct path *path, struct path *root,
> >                 if (dentry == root->dentry && vfsmnt == root->mnt)
> >                         break;
> >                 if (dentry == vfsmnt->mnt_root || IS_ROOT(dentry)) {
> > +                       /* Escaped? */
> > +                       if (dentry != vfsmnt->mnt_root) {
> > +                               retval = tail;
> > +                               *retval = '/';
> 
> Now we overwrite the null terminator.

Good catch!

> > +                               goto out;
> > +                       }
> >                         /* Global root? */
> >                         if (vfsmnt->mnt_parent == vfsmnt) {
> >                                 goto global_root;
> 
> Also, nothing inserts the "(unreachable)" string.  I've attached my
> version, which deals with both of these.

Thanks, I've queued this one instead!

Willy

Re: [PATCHES] Bind mount escape fixes (CVE-2015-2925)

[Greg Kroah-Hartman]

On Thu, Oct 01, 2015 at 11:15:47AM -0500, Eric W. Biederman wrote:
> 
> With a strategically placed rename bind mounts can be tricked into
> giving processes access to the entire filesystem instead of just a piece
> of it.  This misfeature has existed since bind mounts were introduced
> into the kernel.  This issue has been fixed in Linus's tree and below
> are my tested backports of the fixes to 4.2.1, 4.1.8, 3.18.21, 3.14.53,
> 3.12.48, 3.10.89, 3.4.109, 3.2.71, 2.6.32.68.  All of the kernels 
> currently listed as being active.
> 
> The fixes backported are:
> cde93be45a8a90d8c264c776fab63487b5038a65 dcache: Handle escaped paths in prepend_path
> 397d425dc26da728396e66d392d5dcb8dac30c37 vfs: Test for and handle paths that are unreachable from their mnt_root
> 
> As I backported the patches the logical work remained the same but the
> exact implemenation details changed to fit in with the vfs present in
> the older kernels.  Minor changes were needed for every the backport to
> every kernel except 4.2.1.
> 
> Please queue these changes for the appropriate stable trees.
> 

Thanks for these, now applied to 4.2, 4.1, 3.14, and 3.10 stable trees.

greg k-h








> 
> Eric