FROM BUGTRAQ AT SECURITYFOCUS: http://www.securityfocus.com/templates/archive.pike?start=2000-10-08&mid=139128&fromthread=0&list=1&threads=0&end=2000-10-14& OVERVIEW PHP is a commonly used HTML-embedded scripting language. Format string vulnerabilities exist in the error logging routines of PHP versions 3 and 4, allowing remote users to execute arbitrary code under the web server's user id. A web server having PHP installed and one or more PHP scripts is vulnerable to the problem if error logging is enabled in php.ini. Also any PHP script using the "syslog" command of PHP may be vulnerable, regardless of error logging. The problem was tested on a Red Hat Linux system having Apache and mod_php3 installed. Error logging was enabled in php.ini. With a test exploit program, a shellcode could be run remotely under the web server user id, which is typically not the root user. BUG DETAILS In main.c, function php3_log_error(): #if HAVE_SYSLOG_H if (!strcmp(php3_ini.error_log, "syslog")) { syslog(LOG_NOTICE, log_message); return; } else { #endif log_file = fopen(php3_ini.error_log, "a"); if (log_file != NULL) { fprintf(log_file, log_message); ... This one is a classical "format bug". There are a couple of other similar fprintf() calls in the same function, as well as Apache API function calls to aplog_error() and log_error() which all use the log_message as a format string. The message can be trivially generated with any php3 script on a web server, for example by sending a POST request with content-type "multipart/form-data" but without a boundary string. A shellcode and other data may be placed in the error message. The error message can be generated without the script actually wanting to process any POST data. Another format bug in functions/syslog.c, function php3_syslog: syslog(priority->value.lval, message->value.str.val); The "syslog" command of PHP takes two parameters, the priority/facility number and the message itself. The message is always passed to libc syslog() as a format string. Thus any program doing syslogging may be vulnerable to a format string attack; details depend on the script in question. The code fragments above are taken from PHP 3 sources, but the vulnerabilities exist in PHP version 4 too. SOLUTION Authors of PHP have been contacted (two weeks ago) and they have released new versions of the software. OS vendors have been contacted as well and they have, or will release fix packages shortly. A temporary workaround is to disable error logging in php.ini, and disable any PHP scripts that use the syslog command. A new fixed version of PHP 4 is downloadable at http://www.php.net/do_download.php?download_file=php-4.0.3.tar.gz CREDITS Vulnerability discovered by: Jouko Pynnvnen <jouko>
php 4.0.3pl1 would be better as there are problems with php-4.0.3
php-4.0.3pl1 is broken too (at least the target_platform for building a DSO target) a new php-4.0.3pl1-redhat.patch is needed, adding -I./TSRM to build_ext() and using ./configure --target=i686-pc-linux-gnu on compile() attaching patches
Created attachment 4268 [details] patch from the spec on php-4.0.2-2
Created attachment 4269 [details] -redhat patch for 4.0.3pl1 (configuration changes)
An errata is already in the pipeline.