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

["bugdal at aerifal dot cx" <sourceware-bugzilla at sourceware dot org>]

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.