ID: 15384 Updated by: [EMAIL PROTECTED] Reported By: [EMAIL PROTECTED] -Status: Open +Status: Duplicate Bug Type: Apache related Operating System: All Windows Versions PHP Version: 4.1.1 New Comment:
This is a dupe... Previous Comments: ------------------------------------------------------------------------ [2002-02-05 07:20:21] [EMAIL PROTECTED] This has been reported before, and the documentation has been amended. Due to significant upgrades in the SAPI module for windows under both IIS and Apache, there is now no longer a need to use the binary. >From exploration it would seem that there is no other way to run PHP as a binary, with apache. The suggested action is to change the scriptalias name, so it's harder or impossible to work out where the PHP binary is - however we accept that that is not a wonderfull solution. a better one is being investigated. ------------------------------------------------------------------------ [2002-02-05 05:55:50] [EMAIL PROTECTED] As advised in the installation text that comes with all versions of PHP, when installing PHP.EXE for use on a windows machine installed with Apache, the user should insert a few lines of code into the Apache "httpd.conf". These exact lines are shown here: ScriptAlias /php/ "c:/php/" AddType application/x-httpd-php .php Action application/x-httpd-php "/php/php.exe" A security vulnerability arises when placing the ScriptAlias line above. This line effectively maps the alias /php/ to your web document root such that typing "http://www.example.com/php/" will actually try to access in this case "c:\php\". Please note that the last "/" on the end of the URL has to exist for this to work ("http://www.example.com/php" will not work). At this point your server will respond with "Access Denied", however if you now specify the URL "http://www.example.com/php/php.exe" , you will see the error "No input file specified". This error is actually returned by php.exe, which you have just executed on the server. There are many exploits that can happen with this setup (some very serious, which could be used to gain root access). Details Exploit 1: It is possible to read any file remotely on the server, even across drives with the following URL construct: "http://www.example.com/php/php.exe?c:\winnt\repair\sam" PHP.EXE will parse the sam file "c:\winnt\repair\sam" and return it to the browser for download (this is the Windows NT password file). "http://www.example.com/php/php.exe?d:\winnt\repair\sam" PHP.EXE will return the same file on the D: drive. The above SAM file can then be used to decrypt all the Account Passwords for the Server. Exploit 2: If you specify a file that exists in the php directory (different files exist depending on the version of PHP), the web server will try to execute this file and will throw back an error reporting the install directory of php. So in PHP4, for example, you would specify the following line: "http://www.example.com/php/php4ts.dll" The error returned by the web server would be: " couldn't create child process: 22693: C:/php/php4ts.dll " showing the install path of PHP. ------------------------------------------------------------------------ -- Edit this bug report at http://bugs.php.net/?id=15384&edit=1 -- PHP Development Mailing List <http://www.php.net/> To unsubscribe, visit: http://www.php.net/unsub.php