[Bug 192138] New: pw useradd and pw groupadd existence check races

[bugzilla-noreply at freebsd.org]

https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=192138

            Bug ID: 192138
           Summary: pw useradd and pw groupadd existence check races
           Product: Base System
           Version: 10.0-STABLE
          Hardware: Any
                OS: Any
            Status: Needs Triage
          Severity: Affects Some People
          Priority: ---
         Component: bin
          Assignee: freebsd-bugs at FreeBSD.org
          Reporter: sheets at alum.mit.edu

pw useradd has a race between checking if the username is already in use and
updating the pw database:

getpwnam check
<https://svnweb.freebsd.org/base/head/usr.sbin/pw/pw_user.c?revision=267970&view=markup#l602>

addpwent
<https://svnweb.freebsd.org/base/head/usr.sbin/pw/pw_user.c?revision=267970&view=markup#l712>
with useless return value check

pw_update without check or nonzero return inside of lock
<https://svnweb.freebsd.org/base/head/usr.sbin/pw/pwupd.c?revision=267670&view=markup#l126>

pw groupadd has a race between checking if the groupname is already in use and
updating the gr database:

getgrnam check
<https://svnweb.freebsd.org/base/head/usr.sbin/pw/pw_group.c?revision=262864&view=markup#l102>

addgrent
<https://svnweb.freebsd.org/base/head/usr.sbin/pw/pw_group.c?revision=262864&view=markup#l260>
with useless return value check

gr_update without check or nonzero return inside of lock
<https://svnweb.freebsd.org/base/head/usr.sbin/pw/grupd.c?revision=243898&view=markup#l71>

This race is exhibited when multiple processes attempt to use the error return
code of useradd/groupadd to indicate whether they have successfully created a
unique user for themselves. If the race occurs, the uid/gid of the database
entry may change out from under the first successful process as the second
process finds an unused uid/gid and then updates the database using the same
key (but the new uid/gid).

I don't believe this bug is a security vulnerability except in contexts where
attackers may have control over user/group creation by applications assuming
that the database locks ensure non-collision.

pw useradd/groupadd should either consistently let the operator overwrite
existing groups/users or should consistently produce a name collision error

pw groupadd/useradd sometimes exits due to a name collision and sometimes
overwrites existing groups/users

-- 
You are receiving this mail because:
You are the assignee for the bug.