I suppose this vulnerability affects also debian. I've already changed the
setuid bit in chfn and chsh though it is supposed to be difficult to exploit.
-- Missatge transmès --
Subject: RAZOR advisory: Linux util-linux chfn local root vulnerability
Date: Mon, 29 Jul 2002 10:51:50 -0400 (EDT)
From: Michal Zalewski <[EMAIL PROTECTED]>
To: bugtraq@securityfocus.com, <[EMAIL PROTECTED]>
Linux util-linux chfn local root vulnerability
Issue Date: July 29, 2002
Contact: Michal Zalewski
CVE: CAN-2002-0638
CERT vulnerability note: http://www.kb.cert.org/vuls/id/405955
(the URL should be accessible soon)
Topic:
A locally exploitable vulnerability is present in the util-linux
package shipped with Red Hat Linux and numerous other Linux
distributions.
Affected Systems:
Red Hat Linux 7.3 and previous; potentially many other distributions
up to date that use util-linux to provide chfn and chsh utilities.
Please refer to the CERT vulnerability note for more information.
Systems that ship chfn within the shadow-utils package (for example
SuSE) are not vulnerable.
Details:
The vulnerability is present within the shared code of the util-linux
package. For the purpose of this discussion, we use the setuid
application 'chfn' as an attack vector. We used the "Fenris" utility,
available at http://razor.bindview.com/tools/fenris, to analyze the
issue.
The purpose of the 'chfn' utility is to allow users to modify personal
information stored within the system-wide password file, /etc/passwd.
In order to modify this file, this application must be installed
setuid root. It is a part of the base installation of most Linux
systems.
Under certain commonly met conditions (see "Mitigating Factors"), a
carefully crafted attack sequence can be performed to exploit a
complex file locking and modification race present in this utility,
and, as a result, alter /etc/passwd to escalate privileges in the
system.
Password file locking and modification code can be found in util-linux
within the login-utils/setpwnam.c file. The general logic used for
this process is as follows:
1. /etc/ptmptmp file is opened with O_WRONLY|O_CREAT, 0644 perms
2. the file is linked to /etc/ptmp, exit on failure
3. /etc/ptmptmp is removed
Later, the descriptor obtained in step 1 is used for writing to
construct the new /etc/passwd contents. This is done line by line, by
calling the fputs() routine. When the new file is ready, three more
steps are taken:
4. /etc/passwd.OLD is removed
5. /etc/passwd is linked to /etc/passwd.OLD
6. /etc/ptmp is renamed to /etc/passwd
At first sight, this logic is not flawed. There is no O_EXCL in step
1, but step 2 works as an accurate exclusive locking mechanism, and
prevents other instances of this application from making any writes
until the procedure is completed (step 6). Also, step 3 ensures that
no process will work on the hardlink of /etc/passwd after the
procedure is completed. This, while is not a standard way of handling
file locking on Linux, is an adequate protection against race
conditions. The only concern is that if chfn, chsh, or any other
process that uses /etc/ptmp is terminated abnormally (e.g. never exits
because of a system crash or is killed with SIGKILL), the lock has to
be removed manually in order for applications that rely on this
signaling method to work properly. This includes utilities such as
chsh, chfn, useradd, userdel, adduser, vipw and other software. Most
of seasoned Linux administrators have had to remove this lock file at
least once, and many utilities offer help troubleshooting this issue -
for example, adduser refuses to run when /etc/ptmp is present and
terminates with the following message:
# adduser
vipw lockfile (/etc/ptmp) is present!
This is exactly what causes the problem. Because this dangling lock
file makes it impossible to perform regular user management tasks, it
is trivial to force the administrator to remove it. This is a risk if
chfn is stopped (by SIGSTOP) between steps 2 and 3 - which can be
done. There is a very small window of opportunity here, but it is
possible to fit into it. Later, the application can be resumed with
SIGCONT.
Note that there is no easy way to diagnose who created /etc/ptmp and
for what reason they created it. The file is owned by root and has no
additional information whatsoever. The attack relies on small windows
of opportunity, making one-shot attempts not feasible on certain
systems, it is reasonable to expect that if the attacker repeatedly
runs chfn or chsh just to create dangling lock files several times a
day - and to make user management and maintenance tasks repeatedly
fail because of this lockfile - the administrator will most likely add
"rm -f /etc/ptmp" or equivalent to his cronta
