|Summary:||pw useradd and pw groupadd existence check races|
|Component:||bin||Assignee:||freebsd-bugs (Nobody) <bugs>|
|Severity:||Affects Some People||CC:||mjg, simon|
Description sheets 2014-07-26 17:27:23 UTC
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
Comment 1 Mateusz Guzik 2014-07-26 17:30:37 UTC
Not only that, pw is racy in general w.r.t other operations. An acceptable way around this would be to have a lock (say, /etc/.pw.lock) which is taken at the beginning and released at the end. Preferably also supported by other tools playing with passwd (and other files).