#314 Minor security flaw with pam_xauth

bugfix
closed-works-for-me
modules (176)
5
2010-08-03
2010-07-12
Tim Brown
No

I was recently carrying out some source code auditing and spotted a minor flaw in pam_xauth. This PAM module (when enabled) attempts do ensure that a users xauth cookies are added for the target user when the user is switched using the su command. The flaw lies in the fact that run_coprocess() which is responsible for running "xauth nlist ..." as the existing user and "xauth merge" as the target user does not check the return code on the setuid() call:

From pam-1.1.1/modules/pam_xauth/pam_xauth.c:

89 static int
90 run_coprocess(const char *input, char **output,
91 uid_t uid, gid_t gid, const char *command, ...)
92 {
...
128 /* Drop privileges. */
129 setgid(gid);
130 setgroups(0, NULL);
131 setuid(uid)
...
156 execv(command, args);
157 /* Never reached. */
158 _exit(1);
159 }

An attacker with the ability to manipulate the number of processes running on the target account can cause RLIMIT_NPROC to be breached when run_coprocess is called to execute "xauth merge" as the target user:

386 /* Get the target user's UID and primary GID, which we'll need to set
386 * on the xauthority file we create later on. */
387 tpwd = pam_modutil_getpwnam(pamh, user);
...
672 run_coprocess(cookie, &tmp,
673 tpwd->pw_uid, tpwd->pw_gid,
674 xauth, "-f", cookiefile, "nmerge", "-", NULL);

Whilst I do not believe that this is trivially exploitable, perhaps the code could be refactored to ensure that run_coprocess correctly drops privileges. As things stand any code after the setuid() call at line 131, could be forced to run with inappropriate privileges by an attacker with existing access to the target account. by causing RLIMIT_NPROC resource to be breached.

Discussion

  • Tim Brown

    Tim Brown - 2010-07-20

    Unhidden due to lack of response

     
  • Thorsten Kukuk

    Thorsten Kukuk - 2010-08-03
    • assigned_to: nobody --> kukuk
    • status: open --> closed-works-for-me
     
  • Thorsten Kukuk

    Thorsten Kukuk - 2010-08-03

    I fail to see how RLIMIT_NPROC should have any affect on setuid. setuid() can only fail if the process does not have the privileges to change the uid (which means it runs already as that user, not root), or if the UID is invalid (can only happen if admin enters an invalid UID in /etc/passwd). setuid cannot fail because no more processes are allowed.

     
  • Tim Brown

    Tim Brown - 2010-08-09

    As per my email, the setuid(2) man page from one of my Debian hosts states that:
    ...
    ERRORS:
    EAGAIN The uid does not match the current uid and uid brings process over its
    RLIMIT_NPROC resource limit.
    ...

    Granted this is a Linux specific behaviour but given the wide spread use of PAM
    in Linux distros it's a significant user base. FWIW I actually patched up a
    copy of pam_xauth to print the users UID at various points through the process
    (particularly the two calls to run_coprocess()) and by manipulating the number
    of running processe belonging to the initial and target users I was able to
    force the various calls to setuid() to fail and thus subsequent code to run with the incorrect privileges. Like I said in the original bug entry, I don't
    think this is exploitable, but other similar cases have been so it should probably be fixed. Just as one example, see the oss-security discussion about a similar bug in oping:

    http://marc.info/?l=oss-security&m=125561799830836&w=2

     

Log in to post a comment.