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