Bug 18965 - PHP remote format string vulnerabilities
Summary: PHP remote format string vulnerabilities
Keywords:
Status: CLOSED ERRATA
Alias: None
Product: Red Hat Linux
Classification: Retired
Component: php
Version: 7.0
Hardware: All
OS: Linux
high
medium
Target Milestone: ---
Assignee: Nalin Dahyabhai
QA Contact: Dale Lovelace
URL: http://www.securityfocus.com/template...
Whiteboard:
Depends On:
Blocks:
TreeView+ depends on / blocked
 
Reported: 2000-10-12 15:23 UTC by Ricardo Ariel Gorosito
Modified: 2007-03-27 03:36 UTC (History)
3 users (show)

Fixed In Version:
Doc Type: Bug Fix
Doc Text:
Clone Of:
Environment:
Last Closed: 2000-10-17 21:51:22 UTC
Embargoed:


Attachments (Terms of Use)
patch from the spec on php-4.0.2-2 (1.25 KB, patch)
2000-10-17 13:34 UTC, Arenas Belon, Carlo Marcelo
no flags Details | Diff
-redhat patch for 4.0.3pl1 (configuration changes) (2.26 KB, patch)
2000-10-17 13:35 UTC, Arenas Belon, Carlo Marcelo
no flags Details | Diff

Description Ricardo Ariel Gorosito 2000-10-12 15:23:50 UTC
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>

Comment 1 Arenas Belon, Carlo Marcelo 2000-10-17 08:09:45 UTC
php 4.0.3pl1 would be better as there are problems with php-4.0.3

Comment 2 Arenas Belon, Carlo Marcelo 2000-10-17 13:29:59 UTC
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

Comment 3 Arenas Belon, Carlo Marcelo 2000-10-17 13:34:24 UTC
Created attachment 4268 [details]
patch from the spec on php-4.0.2-2

Comment 4 Arenas Belon, Carlo Marcelo 2000-10-17 13:35:34 UTC
Created attachment 4269 [details]
-redhat patch for 4.0.3pl1 (configuration changes)

Comment 5 Nalin Dahyabhai 2000-10-17 21:51:19 UTC
An errata is already in the pipeline.


Note You need to log in before you can comment on or make changes to this bug.