6823322 2001-07-31 13:56 +0100  /119 rader/ Carl Livitt <carl@ititc.com>
Sänt av: joel@lysator.liu.se
Importerad: 2001-07-31  18:12  av Brevbäraren
Extern mottagare: bugtraq@securityfocus.com
Mottagare: Bugtraq (import) <18531>
Ärende: New command execution vulnerability in myPhpAdmin
------------------------------------------------------------
From: Carl Livitt <carl@ititc.com>
To: bugtraq@securityfocus.com
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
(6823322) /Carl Livitt <carl@ititc.com>/--(Ombruten)
Kommentar i text 6824847 av Mark Renouf <mark@tweakt.net>
6824847 2001-07-31 17:16 -0400  /27 rader/ Mark Renouf <mark@tweakt.net>
Sänt av: joel@lysator.liu.se
Importerad: 2001-07-31  23:33  av Brevbäraren
Extern mottagare: Carl Livitt <carl@ititc.com>
Extern kopiemottagare: bugtraq@securityfocus.com
Mottagare: Bugtraq (import) <18548>
Kommentar till text 6823322 av Carl Livitt <carl@ititc.com>
Ärende: Re: New command execution vulnerability in myPhpAdmin
------------------------------------------------------------
From: Mark Renouf <mark@tweakt.net>
To: Carl Livitt <carl@ititc.com>
Cc: bugtraq@securityfocus.com
Message-ID: <3B672021.1030109@tweakt.net>

Carl Livitt wrote:

>--/ 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
>
This isn't so much a problem with phpMyAdmin as it is with PHP in 
general. I would HIGHLY
recommend turning off  register_globals in php.ini (which is the default 
in set in php.ini-dist for php4+).
With that option disabled, the only thing that passing in extra 
parameters can do is create entries in
the $HTTP_GET_VARS array, and it's not possible to clobber global script 
variables.

I tested this with my installation of phpMyAdmin 2.1.0 and it is not 
vulnerable to the attack that you
described, due to the settings I mentioned above.
(6824847) /Mark Renouf <mark@tweakt.net>/-----------
Kommentar i text 6825026 av Heikki Korpela <heko@iki.fi>
6825026 2001-08-01 00:35 +0300  /24 rader/ Heikki Korpela <heko@iki.fi>
Sänt av: joel@lysator.liu.se
Importerad: 2001-08-01  00:02  av Brevbäraren
Extern mottagare: Mark Renouf <mark@tweakt.net>
Extern kopiemottagare: bugtraq@securityfocus.com
Externa svar till: heko@iki.fi
Mottagare: Bugtraq (import) <18549>
Kommentar till text 6824847 av Mark Renouf <mark@tweakt.net>
Ärende: Re: New command execution vulnerability in myPhpAdmin
------------------------------------------------------------
From: Heikki Korpela <heko@iki.fi>
To: Mark Renouf <mark@tweakt.net>
Cc: <bugtraq@securityfocus.com>
Message-ID: <Pine.LNX.4.33.0108010032040.1931-100000@saitti.net>

On Tue, 31 Jul 2001, Mark Renouf wrote:

> I would HIGHLY
> recommend turning off  register_globals in php.ini (which is the default
> in set in php.ini-dist for php4+).

This is incorrect. Currently register_globals is by default
On, and most scripts out there assume that it is so. Whether or not
it will remain as so is still open for discussion.

Also see Rasmus Lerdorf's proposal:

	http://marc.theaimsgroup.com/?l=php-dev&m=99638397319055&w=2

-- 
<---------------------------------------------------------------------->
          Heikki Korpela -- heko@iki.fi -- http://iki.fi/heko/
(6825026) /Heikki Korpela <heko@iki.fi>/------------