martin carpenter

contents

solaris issetugid(2) bug

2013/01/15

tags: solaris issetugid(2) vulnerability

summary

Child processes forget that they were once privileged in spite of the fact that they continue to possess differing real and effective user IDs. This could be a security problem for any program that relies on the issetugid(2) system call to return valid results.

Oracle have subsequently fixed this in Solaris 11.1 but not in earlier releases. In particular Solaris 10 has not been fixed and therefore applications should avoid using this system call on this version of the operating system.

bug details

issetugid(2) was a new system call for Solaris 10. It was intended to track the "setuidness" of an invoked program, no matter whether or not it subsequently called setuid() or if it fork()ed or exec()ed another program. The manual page says:

 The result of a call to issetugid() is unaffected  by  calls
 to  setuid(),  setgid(),  or other such calls.  In case of a
 call to fork(2), the child process inherits the same status.

Unfortunately issetugid() fails to preserve its value after forking children from a setuid program when uid != euid in both Solaris 10 and 11.

Here is a simple demonstration program foo.c:

#include <stdio.h>
#include <sys/types.h>
#include <unistd.h>
#include <sys/wait.h>
#include <stdlib.h>

int main(int argc, const char *argv[])
{
    pid_t pid = 0;
    int stat_loc = 0;
    const char *execname = getexecname();

    printf("%s: main:   issetugid: %u\n", execname, issetugid());

    pid = fork();
    switch(pid) {
        case -1:
            perror("fork");
            break;
        case 0: 
            printf("%s: child:  issetugid: %u\n", execname, issetugid());
            printf("%s: child:  uid:       %u\n", execname, getuid());
            printf("%s: child:  euid:      %u\n", execname, geteuid());
            break;
        default:
            printf("%s: parent: issetugid: %u\n", execname, issetugid());
            printf("%s: parent: uid:       %u\n", execname, getuid());
            printf("%s: parent: euid:      %u\n", execname, geteuid());
            (void)wait(&stat_loc);
            break;
    }

    return 0;
}

And the results of running it:

alice@sol10:~$ gcc -o foo foo.c
alice@sol10:~$
alice@sol10:~$ ./foo
foo: main:   issetugid: 0
foo: parent: issetugid: 0
foo: parent: uid:       1000
foo: parent: euid:      1000
foo: child:  issetugid: 0
foo: child:  uid:       1000
foo: child:  euid:      1000
alice@sol10:~$
alice@sol10:~$ sudo chown root foo
alice@sol10:~$ sudo chmod 4755 foo
alice@sol10:~$ ./foo
foo: main:   issetugid: 1
foo: parent: issetugid: 1
foo: parent: uid:       1000
foo: parent: euid:      0
foo: child:  issetugid: 0       # oops
foo: child:  uid:       1000
foo: child:  euid:      0
alice@sol10:~$

Since the genealogy of this system call is BSDish, I tested the same program on FreeBSD 9.0 where issetugid() returns 1 in both the parent and child, as expected.

exploitability

Fortunately issetugid() is relatively new and not greatly used. I took a quick tour through OpenSolaris and found it in the following libraries/library calls:

• catopen(3)
• libscf(3LIB)
• libuutil(3LIB) (calling function appears unused)
• libumem(3LIB) (implements own issetugid()?)

fork()/catopen() occur in, for example, the following setuid root binaries:

• sdtcm_convert(1)
• dtprintinfo(1)
• ...

None of these look directly exploitable, principally because conditions required are quite strict:

• setuid binary
• forks (or fork/execs)
• then relies on issetugid() in a way that can be exploited

fork()/exec()/catopen() certainly feels like it should be a good lever though, in particular when programs are executed from su(1) or sudo(1).

Since a direct exploit could not be found Oracle fixed this under the Security in Depth programme as noted in the January 2013 Critical Patch Update. A CVE was not allocated.

timeline

• 2012/06/15 reported to Oracle security.
• 2012/06/19 assigned tracking number S0185383.
• 2012/06/21 assigned bug tracker number 7177968.
• 2012/07/04 assigned to Oracle's "defence in depth" programme since they "couldn't find a way to directly exploit this issue".
• 2012/10/17 Oracle Critical Patch Update released... no mention.
• 2012/10/19 Oracle confirmed "... this was a mistake. The fix is in progress...".
• 2012/12/19 Oracle confirmed patch for January's Critical Patch Update for Solaris 11.1 but not earlier releases.
• 2012/12/21 I indicated that not fixing a security-related bug in a system call on Solaris 10 is less than ideal (how do Oracle know how this is being used?) but good that they will acknowledge issue. No response.
• 2013/01/15 Oracle Critical Patch Update with accredited fix for Solaris 11.