imwheel Predictable Temporary File May Let Local Users Gain Elevated Privileges
SecurityTracker Alert ID: 1011049|
SecurityTracker URL: http://securitytracker.com/id/1011049
(Links to External Site)
Date: Aug 25 2004
Denial of service via local system, Modification of system information, Modification of user information, User access via local system|
Exploit Included: Yes |
A vulnerability was reported in imwheel. A local user may be able to gain elevated privileges.|
I)ruid of Computer Academic Underground reported that the software uses a process ID (PID) file with a predictable file name ('/tmp/imwheel.pid'). A local user can exploit a race condition in the '-k' command-line option (used to kill imwheel processes) to cause denial of service conditions or to append to files with the privileges of the target user.
A local user can create a symbolic link (symlink) from a file on the system to the PID file. Then, when imwheel is executed, imwheel will append the PID to the symlinked file with the privileges of the user running imwheel. A local user may be able to exploit this to obtain the privileges of the target user.
A local user can also take control of the PID file to prevent other non-root users from using imwheel because imwheel will not be able to write to the PID file.
A local user can also take control of the PID file and continuously delete the contents of the file to cause imwheel to be unable to kill imwheel processes, potentailly causing resource exhaustion.
The original advisory is available at:
A local user may be able to gain the privileges of a user running imwheel.|
A local user may be able to prevent other users from running imwheel.
A local user may be able to consume excessive resources on the target system.
No solution was available at the time of this entry.|
Vendor URL: imwheel.sourceforge.net/ (Links to External Site)
Access control error, State error|
|Underlying OS: Linux (Any)|
Source Message Contents
Subject: [Full-Disclosure] CAU-2004-0002 - imwheel Predictable PidFile Name Race Condition|
____ ____ __ __
/ \ / \ | | | |
----=3D=3D=3D=3D####/ /\__\##/ /\ \##| |##| |####=3D=3D=3D=3D-=
| | | |__| | | | | |
| | ___ | __ | | | | |
------=3D=3D=3D=3D=3D=3D######\ \/ /#| |##| |#| |##| |######=3D=3D=
\____/ |__| |__| \______/
Computer Academic Underground
Advisory ID: CAU-2004-0002
Release Date: 06/24/2004
Title: imwheel Predictable PidFile Name Race Condition
Application/OS: imwheel 1.0.0pre11 (Linux/X11)
Topic: imwheel's behavior regarding a predictably named pidfile
introduces many security issues via a race condition.
Vendor Status: Notified on 06/10/2004 via SourceForge, no response.
Attributes: Denial of Service, Resource Exhaustion, Arbitrary File
Advisory URL: http://www.caughq.org/advisories/CAU-2004-0002.txt
Author/Email: I)ruid <email@example.com>
imwheel exclusively uses a predictably named PID file for management of
multiple imwheel processes. A race condition exists when the -k
command-line option is used to kill existing imwheel processes. This
race condition may be used by a local user to Denial of Service another
user using imwheel, lead to resource exhaustion of the host system, or
append data to arbitrary files.
Three separate issues may be inflicted by a successful race attack
against the imwheel PID file.
In the first case, a legitimate user may not be able to further use
imwheel due to a malicious user taking control of the PID file. This
will cause the imwheel process to be unable to write to the PID file and
not start up properly. This case does not exist if imwheel is suid
root or run by the root account, as those permissions will allow the PID
to be written properly to the pidfile.
In the second case, a malicious user may steal control of and constantly
wipe the contents of the PID file, causing imwheel to be unable to
detect and kill existing imwheel processes when it is started with the
-k command-line option, eventually leading to resource exhaustion.
In the third case, a malicious user may symlink the pidfile to an
arbitrary file. If the permissions of the user running imwheel allows,
imwheel will append it's PID to the arbitrary file, potentially causing
corruption of data. The severity of this case is compounded if imwheel
is suid root or run by the root account.
imwheel is developed for the Linux operating system and is a tool to be
used under the X window environment.
imwheel uses a predictably named PID file to store process IDs of
currently running imwheel processes. By default, this file is
/tmp/imwheel.pid. If this file exists when imwheel starts, it appends
it's PID to the file. If imwheel is started with the -k command-line
option to kill all existing imwheel processes, imwheel calls the
KillIMWheel() function in util.c to step through this file PID by PID,
check via the /proc filesystem that the PID's name is imwheel, kill the
process, then repeats for the remaining PIDs in the pidfile. When it
has finished with each PID in the file, the file is unlinked, then re-
created by the new process which writes it's PID to the file. This
behavior creates a race condition where a malicious user may write to
the pidfile during this time window. If imwheel is executed by a local
user, this may prevent imwheel from starting properly if the pidfile's
permissions do not allow the user to write to the pidfile, resulting in
ERROR: Couldn't write pid to pid file
Perhaps you want the -p option to avoid this...
Otherwise you may SUID root the imwheel executable.
: Permission denied
If the user executing imwheel does have permissions to write to the
pidfile, imwheel will start properly, however the pidfile will still be
owned by the malicious user, who may then wipe out the contents of the
pidfile, causing further instances of imwheel run with the -k option to
not properly shut down existing instances of imwheel, eventually causing
resource exhaustion. Further, a malicious user could symlink the
pidfile to any arbitrary file on the system, causing imwheel to append
it's PID to the file, potentially causing corruption of data.
Solution & Recommendations
We are currently unaware of any vendor-provided solution to this issue.
A workaround is to use imwheel's --pid|-p option to cause imwheel to run
without checking or using PID files. This will prevent the local user
DoS issue, however imwheel's --kill|-k option will not function
Exploitation of this race condition is trivial with a shell script:
# you may have to adjust the number of characters in the print to
# get the timing correct for the injection. Fewer characters seems
# to prevent this from working. Optionally, replacing the echo
# with the symlink creation at the end of this script seems to work
# fairly regularly.
echo `perl -e 'print "9" x $CHARCOUNT;'` > /tmp/imwheel.pid
while [[ $? !=3D 0 ]]; do
echo `perl -e 'print "9" x $CHARCOUNT;'` > /tmp/imwheel.pid
# Wait for imwheel to write it's pid to the new file
# Wipe the contents of the PID file.
echo > /tmp/imwheel.pid
# Optionally, replace the new file with a link
# rm /tmp/imwheel.pid
# ln -s /etc/group /tmp/imwheel.pid
echo "Exploit Successful!!!"
IMWheel - http://imwheel.sourceforge.net/
This advisory has been submitted to BugTraq repeatedly, each time
returned with the apparently customary 'no action has been taken on your
post' message, therefore this advisory has been cross-posted to other
Content-Type: application/pgp-signature; name=signature.asc
Content-Description: This is a digitally signed message part
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.2.2 (GNU/Linux)
-----END PGP SIGNATURE-----
Full-Disclosure - We believe in it.
Go to the Top of This SecurityTracker Archive Page