[Bug nptl/13347] New: Threaded setuid() can wrongly report success when failing to drop privileges

[Bug nptl/13347] New: Threaded setuid() can wrongly report success when failing to drop privileges

[bugdal at aerifal dot cx]

http://sourceware.org/bugzilla/show_bug.cgi?id=13347

             Bug #: 13347
           Summary: Threaded setuid() can wrongly report success when
                    failing to drop privileges
           Product: glibc
           Version: unspecified
            Status: NEW
          Severity: normal
          Priority: P2
         Component: nptl
        AssignedTo: drepper.fsp@gmail.com
        ReportedBy: bugdal@aerifal.cx
    Classification: Unclassified


Created attachment 6035
  --> http://sourceware.org/bugzilla/attachment.cgi?id=6035
Test case that demonstrates the race on pre-3.1 kernels

The "setxid" system by which glibc/nptl synchronizes uid/gid changes using
signals fails to check the return value of the system call in any thread but
the original caller. Thus, it is possible for some threads to retain their
original uid (e.g. root) permanently after setuid(somebody) returns success.

The main cause of failure of setuid at the kernel level is exceeding
RLIMIT_NPROC, and as far as I know, this failure case has finally been removed
in Linux 3.1. However, it's possible that other temporary resource exhaustion
issues could cause setuid to intermittently fail even on newer kernels.

See the attached test case for a demonstration of the bug that works on pre-3.1
kernels. It might be necessary to adjust the timing to hit the race, but on my
machines it usually hits the race within the first 1-5 iterations.

Note that I am not issuing an advisory or elevating the severity because there
seems to be little or no real-world code that depends on multithreaded
setuid(). Nonetheless, this is a security bug and should be treated seriously.

-- 
Configure bugmail: http://sourceware.org/bugzilla/userprefs.cgi?tab=email
------- You are receiving this mail because: -------
You are on the CC list for the bug.

[Bug nptl/13347] Threaded setuid() can wrongly report success when failing to drop privileges

[bugdal at aerifal dot cx]

http://sourceware.org/bugzilla/show_bug.cgi?id=13347

--- Comment #1 from Rich Felker <bugdal at aerifal dot cx> 2012-03-17 20:37:55 UTC ---
Ping. While this feature (multi-threaded setuid) is unlikely to be used in the
real world, this bug report deals with a vulnerability that should be
addressed.

-- 
Configure bugmail: http://sourceware.org/bugzilla/userprefs.cgi?tab=email
------- You are receiving this mail because: -------
You are on the CC list for the bug.

[Bug nptl/13347] Threaded setuid() can wrongly report success when failing to drop privileges

[bugdal at aerifal dot cx]

http://sourceware.org/bugzilla/show_bug.cgi?id=13347

Rich Felker <bugdal at aerifal dot cx> changed:

           What    |Removed                     |Added
----------------------------------------------------------------------------
         AssignedTo|drepper.fsp at gmail dot    |unassigned at sourceware
                   |com                         |dot org

-- 
Configure bugmail: http://sourceware.org/bugzilla/userprefs.cgi?tab=email
------- You are receiving this mail because: -------
You are on the CC list for the bug.

[Bug nptl/13347] Threaded setuid() can wrongly report success when failing to drop privileges

[ppluzhnikov at google dot com]

http://sourceware.org/bugzilla/show_bug.cgi?id=13347

Paul Pluzhnikov <ppluzhnikov at google dot com> changed:

           What    |Removed                     |Added
----------------------------------------------------------------------------
                 CC|                            |ppluzhnikov at google dot
                   |                            |com

-- 
Configure bugmail: http://sourceware.org/bugzilla/userprefs.cgi?tab=email
------- You are receiving this mail because: -------
You are on the CC list for the bug.

[Bug nptl/13347] Threaded setuid() can wrongly report success when failing to drop privileges

[carlos_odonell at mentor dot com]

http://sourceware.org/bugzilla/show_bug.cgi?id=13347

Carlos O'Donell <carlos_odonell at mentor dot com> changed:

           What    |Removed                     |Added
----------------------------------------------------------------------------
             Status|NEW                         |WAITING
                 CC|                            |carlos_odonell at mentor
                   |                            |dot com

--- Comment #2 from Carlos O'Donell <carlos_odonell at mentor dot com> 2012-07-24 14:51:43 UTC ---
Rich,

Would you be willing to work up a patch to fix this? I can arrange to get
people to review the patch once created and get it into 2.17.

-- 
Configure bugmail: http://sourceware.org/bugzilla/userprefs.cgi?tab=email
------- You are receiving this mail because: -------
You are on the CC list for the bug.

[Bug nptl/13347] Threaded setuid() can wrongly report success when failing to drop privileges

[fweimer at redhat dot com]

http://sourceware.org/bugzilla/show_bug.cgi?id=13347

Florian Weimer <fweimer at redhat dot com> changed:

           What    |Removed                     |Added
----------------------------------------------------------------------------
                 CC|                            |fweimer at redhat dot com

-- 
Configure bugmail: http://sourceware.org/bugzilla/userprefs.cgi?tab=email
------- You are receiving this mail because: -------
You are on the CC list for the bug.

[Bug nptl/13347] Threaded setuid() can wrongly report success when failing to drop privileges

[bugdal at aerifal dot cx]

http://sourceware.org/bugzilla/show_bug.cgi?id=13347

--- Comment #3 from Rich Felker <bugdal at aerifal dot cx> 2012-07-24 18:15:24 UTC ---
Before I try, I'd like to know what level of quality we're aiming for. The
difficulty with this issue is that in the case of failure, the process is in an
inconsistent state (threads do not all have the same uid anymore) and it's
impossible to back-out the partial change. On Linux, I believe that once at
least one thread has successfully changed uid, it's impossible for others to
fail due to ENOMEM (since the same kernelspace privilege object gets used from
the cache); the only possible failure is due to malicious security modules or
RLIMIT_NPROC issues on pre-3.1 kernels.

In musl, I "solved" the issue fully by assuming the above, and refusing to
setuid at all if the real uid will be changed and we can't temporarily set the
rlimit to infinity. There's still code that will return an error if some but
not all threads change uid, but I believe the failure will only happen in the
real world on the first thread to attempt the change, if any.

Without that additional workaround (which may be undesirable to some users..?)
I'm not clear on what setuid should do when some threads succeed and others
fail. Returning -1 with errno set might imply to the caller that the uid was
not changed, and some folks I discussed this with in the security field
recommended that libc should just abort the program rather than return with an
inconsistent state (different uid in different threads), but from a robustness
standpoint this is highly undesirable...

Once there's some agreement on what the policy should be, I can work on a
patch. Short of that, a patch to at least make it fail with the process in an
inconsistent state would be better than the current situation (wrongly
reporting failure).

-- 
Configure bugmail: http://sourceware.org/bugzilla/userprefs.cgi?tab=email
------- You are receiving this mail because: -------
You are on the CC list for the bug.

[Bug nptl/13347] Threaded setuid() can wrongly report success when failing to drop privileges

[carlos_odonell at mentor dot com]

http://sourceware.org/bugzilla/show_bug.cgi?id=13347

--- Comment #4 from Carlos O'Donell <carlos_odonell at mentor dot com> 2012-07-24 18:35:22 UTC ---
(In reply to comment #3)
> Before I try, I'd like to know what level of quality we're aiming for. The
> difficulty with this issue is that in the case of failure, the process is in an
> inconsistent state (threads do not all have the same uid anymore) and it's
> impossible to back-out the partial change. On Linux, I believe that once at
> least one thread has successfully changed uid, it's impossible for others to
> fail due to ENOMEM (since the same kernelspace privilege object gets used from
> the cache); the only possible failure is due to malicious security modules or
> RLIMIT_NPROC issues on pre-3.1 kernels.
> 
> In musl, I "solved" the issue fully by assuming the above, and refusing to
> setuid at all if the real uid will be changed and we can't temporarily set the
> rlimit to infinity. There's still code that will return an error if some but
> not all threads change uid, but I believe the failure will only happen in the
> real world on the first thread to attempt the change, if any.
> 
> Without that additional workaround (which may be undesirable to some users..?)
> I'm not clear on what setuid should do when some threads succeed and others
> fail. Returning -1 with errno set might imply to the caller that the uid was
> not changed, and some folks I discussed this with in the security field
> recommended that libc should just abort the program rather than return with an
> inconsistent state (different uid in different threads), but from a robustness
> standpoint this is highly undesirable...
> 
> Once there's some agreement on what the policy should be, I can work on a
> patch. Short of that, a patch to at least make it fail with the process in an
> inconsistent state would be better than the current situation (wrongly
> reporting failure).

Answering this question and getting some consensus is part of crafting the
solution. Start by emailing libc-alpha@sourceware.org to get input.

IMO the guiding principle to date has been that we should report failure to the
user and let the user decide what to do. Failing to report a failure is worst
possible defect.

Does that make sense?

-- 
Configure bugmail: http://sourceware.org/bugzilla/userprefs.cgi?tab=email
------- You are receiving this mail because: -------
You are on the CC list for the bug.

[Bug nptl/13347] Threaded setuid() can wrongly report success when failing to drop privileges

[bugdal at aerifal dot cx]

http://sourceware.org/bugzilla/show_bug.cgi?id=13347

--- Comment #5 from Rich Felker <bugdal at aerifal dot cx> 2012-07-24 23:04:20 UTC ---
By the user, I assume you mean the calling application. The problem is that
there's no established way to report "something beyond your control went
horribly wrong and you're in an inconsistent state" to the application. You can
report failure, but applications are likely to assume this means the call had
no effect, not that it had a partial effect.

Ultimately, Linux should add a proper setuid syscall that affects all threads
of the current process (thread group) atomically, and glibc should use that if
it's available and only fallback to the ugly method currently in use on older
kernels that don't provide the new syscall.

Anyway I'll start out with a patch to make it report failure, and see where
things go from there...

-- 
Configure bugmail: http://sourceware.org/bugzilla/userprefs.cgi?tab=email
------- You are receiving this mail because: -------
You are on the CC list for the bug.

[Bug nptl/13347] Threaded setuid() can wrongly report success when failing to drop privileges

[carlos_odonell at mentor dot com]

http://sourceware.org/bugzilla/show_bug.cgi?id=13347

--- Comment #6 from Carlos O'Donell <carlos_odonell at mentor dot com> 2012-07-25 02:20:32 UTC ---
(In reply to comment #5)
> By the user, I assume you mean the calling application. The problem is that
> there's no established way to report "something beyond your control went
> horribly wrong and you're in an inconsistent state" to the application. You can
> report failure, but applications are likely to assume this means the call had
> no effect, not that it had a partial effect.
> 
> Ultimately, Linux should add a proper setuid syscall that affects all threads
> of the current process (thread group) atomically, and glibc should use that if
> it's available and only fallback to the ugly method currently in use on older
> kernels that don't provide the new syscall.
> 
> Anyway I'll start out with a patch to make it report failure, and see where
> things go from there...

Thanks Rich, you're work is appreciated.

-- 
Configure bugmail: http://sourceware.org/bugzilla/userprefs.cgi?tab=email
------- You are receiving this mail because: -------
You are on the CC list for the bug.

[Bug nptl/13347] Threaded setuid() can wrongly report success when failing to drop privileges

[carlos at systemhalted dot org]

http://sourceware.org/bugzilla/show_bug.cgi?id=13347

Carlos O'Donell <carlos at systemhalted dot org> changed:

           What    |Removed                     |Added
----------------------------------------------------------------------------
                 CC|carlos_odonell at mentor    |carlos at systemhalted dot
                   |dot com                     |org

-- 
Configure bugmail: http://sourceware.org/bugzilla/userprefs.cgi?tab=email
------- You are receiving this mail because: -------
You are on the CC list for the bug.

[Bug nptl/13347] Threaded setuid() can wrongly report success when failing to drop privileges

[fweimer at redhat dot com]

https://sourceware.org/bugzilla/show_bug.cgi?id=13347

Florian Weimer <fweimer at redhat dot com> changed:

           What    |Removed                     |Added
----------------------------------------------------------------------------
             Status|WAITING                     |ASSIGNED
           Assignee|unassigned at sourceware dot org   |fweimer at redhat dot com

-- 
You are receiving this mail because:
You are on the CC list for the bug.

[Bug nptl/13347] Threaded setuid() can wrongly report success when failing to drop privileges

[bugdal at aerifal dot cx]

https://sourceware.org/bugzilla/show_bug.cgi?id=13347

--- Comment #7 from Rich Felker <bugdal at aerifal dot cx> ---
I'd like to apologize for not following up on this. I started looking into it
back then, but I didn't feel comfortable enough with my understanding of the
code to propose something at the time, and got sidetracked/busy with my own
projects. Perhaps my input is more valuable discussing the issue and offering
feedback on a patch someone else proposes than trying to work on the code
myself.

-- 
You are receiving this mail because:
You are on the CC list for the bug.

[Bug nptl/13347] Threaded setuid() can wrongly report success when failing to drop privileges

[carlos at redhat dot com]

https://sourceware.org/bugzilla/show_bug.cgi?id=13347

--- Comment #8 from Carlos O'Donell <carlos at redhat dot com> ---
(In reply to Rich Felker from comment #7)
> I'd like to apologize for not following up on this. I started looking into
> it back then, but I didn't feel comfortable enough with my understanding of
> the code to propose something at the time, and got sidetracked/busy with my
> own projects. Perhaps my input is more valuable discussing the issue and
> offering feedback on a patch someone else proposes than trying to work on
> the code myself.

That's fine. Feel free to unassign yourself. This is a hard problem to fix. IMO
it requires a new kernel syscall to do setxid in one shot pass or fail.

-- 
You are receiving this mail because:
You are on the CC list for the bug.

[Bug nptl/13347] Threaded setuid() can wrongly report success when failing to drop privileges

[cvs-commit at gcc dot gnu.org]

https://sourceware.org/bugzilla/show_bug.cgi?id=13347

--- Comment #9 from cvs-commit at gcc dot gnu.org <cvs-commit at gcc dot gnu.org> ---
This is an automated email from the git hooks/post-receive script. It was
generated because a ref change was pushed to the repository containing
the project "GNU C Library master sources".

The branch, master has been updated
       via  13f7fe35ae2b0ea55dc4b9628763aafdc8bdc30c (commit)
      from  c859b32e9d76afe8a3f20bb9528961a573c06937 (commit)

Those revisions listed above that are new to this repository have
not appeared on any other notification email; so we list those
revisions in full, below.

- Log -----------------------------------------------------------------
https://sourceware.org/git/gitweb.cgi?p=glibc.git;h=13f7fe35ae2b0ea55dc4b9628763aafdc8bdc30c

commit 13f7fe35ae2b0ea55dc4b9628763aafdc8bdc30c
Author: Florian Weimer <fweimer@redhat.com>
Date:   Mon Mar 24 15:24:02 2014 +0100

    Check for syscall error in the SETXID implementation in NPTL (bug 13347).

    At this point, we can only abort the process because we have already
    switched credentials on other threads.  Returning an error would still
    leave the process in an inconsistent state.

    The new xtest needs root privileges to run.

-----------------------------------------------------------------------

Summary of changes:
 ChangeLog          |    7 +++
 nptl/Makefile      |    3 +-
 nptl/nptl-init.c   |    9 +++-
 nptl/tst-setuid2.c |  145 ++++++++++++++++++++++++++++++++++++++++++++++++++++
 4 files changed, 161 insertions(+), 3 deletions(-)
 create mode 100644 nptl/tst-setuid2.c

-- 
You are receiving this mail because:
You are on the CC list for the bug.

[Bug nptl/13347] Threaded setuid() can wrongly report success when failing to drop privileges

[joseph at codesourcery dot com]

https://sourceware.org/bugzilla/show_bug.cgi?id=13347

--- Comment #10 from joseph at codesourcery dot com <joseph at codesourcery dot com> ---
Please remember to update the list of fixed bugs in NEWS, and to close the 
bug in question in Bugzilla, when checking in a patch that fixes a bug.

-- 
You are receiving this mail because:
You are on the CC list for the bug.

[Bug nptl/13347] Threaded setuid() can wrongly report success when failing to drop privileges

[fweimer at redhat dot com]

https://sourceware.org/bugzilla/show_bug.cgi?id=13347

Florian Weimer <fweimer at redhat dot com> changed:

           What    |Removed                     |Added
----------------------------------------------------------------------------
             Status|ASSIGNED                    |RESOLVED
         Resolution|---                         |FIXED

--- Comment #12 from Florian Weimer <fweimer at redhat dot com> ---
Fixed in 13f7fe35ae2b0ea55dc4b9628763aafdc8bdc30c and
606d8377ae0c7a16d51e3f35eb6f0cf6dce13e5d.

-- 
You are receiving this mail because:
You are on the CC list for the bug.

[Bug nptl/13347] Threaded setuid() can wrongly report success when failing to drop privileges

[cvs-commit at gcc dot gnu.org]

https://sourceware.org/bugzilla/show_bug.cgi?id=13347

--- Comment #11 from cvs-commit at gcc dot gnu.org <cvs-commit at gcc dot gnu.org> ---
This is an automated email from the git hooks/post-receive script. It was
generated because a ref change was pushed to the repository containing
the project "GNU C Library master sources".

The branch, master has been updated
       via  606d8377ae0c7a16d51e3f35eb6f0cf6dce13e5d (commit)
      from  f6c557968c248b4554e708bd08983f0908ac09f1 (commit)

Those revisions listed above that are new to this repository have
not appeared on any other notification email; so we list those
revisions in full, below.

- Log -----------------------------------------------------------------
https://sourceware.org/git/gitweb.cgi?p=glibc.git;h=606d8377ae0c7a16d51e3f35eb6f0cf6dce13e5d

commit 606d8377ae0c7a16d51e3f35eb6f0cf6dce13e5d
Author: Florian Weimer <fweimer@redhat.com>
Date:   Tue Apr 1 14:20:01 2014 +0200

    Update NEWS for fixed bug 13347

-----------------------------------------------------------------------

Summary of changes:
 NEWS |   10 +++++-----
 1 files changed, 5 insertions(+), 5 deletions(-)

-- 
You are receiving this mail because:
You are on the CC list for the bug.

[Bug nptl/13347] Threaded setuid() can wrongly report success when failing to drop privileges

[fweimer at redhat dot com]

https://sourceware.org/bugzilla/show_bug.cgi?id=13347

Florian Weimer <fweimer at redhat dot com> changed:

           What    |Removed                     |Added
----------------------------------------------------------------------------
              Flags|                            |security-

--- Comment #13 from Florian Weimer <fweimer at redhat dot com> ---
I'm flagging this security-, in the hope that this does not affect any
real-world applications.

-- 
You are receiving this mail because:
You are on the CC list for the bug.

[Bug nptl/13347] Threaded setuid() can wrongly report success when failing to drop privileges

[bugdal at aerifal dot cx]

https://sourceware.org/bugzilla/show_bug.cgi?id=13347

--- Comment #14 from Rich Felker <bugdal at aerifal dot cx> ---
I've seen real-world applications that were _potentially_ affected. In
particular, Java applications which call setuid at startup (e.g. after binding
to a port) have often (possibly inadvertently) created threads before doing so.
It may be very unlikely for setuid to fail in some of the threads at system
startup, but if restarting a server that aborted due to some sort of resource
exhaustion, it might be a lot more likely. I never attempted to observe the
issue actually happening in such apps, however; I just noted that it could.

-- 
You are receiving this mail because:
You are on the CC list for the bug.

[Bug nptl/13347] Threaded setuid() can wrongly report success when failing to drop privileges

[fweimer at redhat dot com]

https://sourceware.org/bugzilla/show_bug.cgi?id=13347

Florian Weimer <fweimer at redhat dot com> changed:

           What    |Removed                     |Added
----------------------------------------------------------------------------
           See Also|                            |https://sourceware.org/bugz
                   |                            |illa/show_bug.cgi?id=17135

-- 
You are receiving this mail because:
You are on the CC list for the bug.

[Bug nptl/13347] Threaded setuid() can wrongly report success when failing to drop privileges

[fweimer at redhat dot com]

https://sourceware.org/bugzilla/show_bug.cgi?id=13347

--- Comment #15 from Florian Weimer <fweimer at redhat dot com> ---
(In reply to Rich Felker from comment #14)
> I've seen real-world applications that were _potentially_ affected. In
> particular, Java applications which call setuid at startup (e.g. after
> binding to a port) have often (possibly inadvertently) created threads
> before doing so. It may be very unlikely for setuid to fail in some of the
> threads at system startup, but if restarting a server that aborted due to
> some sort of resource exhaustion, it might be a lot more likely. I never
> attempted to observe the issue actually happening in such apps, however; I
> just noted that it could.

I looked at the Apache jsvc tool, and it changes credentials before
initializing the JVM.  There's a comment suggesting that this dates back to the
LinuxThreads days.  Considering that they also change capabilities (which are
still per-thread and not process-global), there isn't really a way around that.

The jetty-setuid mechanism doesn't check the result of the setuid call, so it's
not vulnerable to this glibc bug, either (because consistent setuid failure
will not result in an abort and leave the service running with elevated
privileges).

Are there any other Java service loaders that could be affected this way, and
for which source code is generally available?

-- 
You are receiving this mail because:
You are on the CC list for the bug.

[Bug nptl/13347] Threaded setuid() can wrongly report success when failing to drop privileges

[bugdal at aerifal dot cx]

https://sourceware.org/bugzilla/show_bug.cgi?id=13347

--- Comment #16 from Rich Felker <bugdal at aerifal dot cx> ---
On Tue, Jul 22, 2014 at 12:34:59PM +0000, fweimer at redhat dot com wrote:
> Are there any other Java service loaders that could be affected this way, and
> for which source code is generally available?

Not that I'm aware of. The examples I saw were non-FOSS and, IIRC,
were not using a webserver or similar but were full java apps (i.e.
the entry point was java code).

-- 
You are receiving this mail because:
You are on the CC list for the bug.