Bugzilla will be upgraded to version 5.0 on a still to be determined date in the near future. The original upgrade date has been delayed.
Bug 18965 - PHP remote format string vulnerabilities
PHP remote format string vulnerabilities
Product: Red Hat Linux
Classification: Retired
Component: php (Show other bugs)
All Linux
high Severity medium
: ---
: ---
Assigned To: Nalin Dahyabhai
Dale Lovelace
: Security
Depends On:
  Show dependency treegraph
Reported: 2000-10-12 11:23 EDT by Ricardo Ariel Gorosito
Modified: 2007-03-26 23:36 EDT (History)
3 users (show)

See Also:
Fixed In Version:
Doc Type: Bug Fix
Doc Text:
Story Points: ---
Clone Of:
Last Closed: 2000-10-17 17:51:22 EDT
Type: ---
Regression: ---
Mount Type: ---
Documentation: ---
Verified Versions:
Category: ---
oVirt Team: ---
RHEL 7.3 requirements from Atomic Host:
Cloudforms Team: ---

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

  None (edit)
Description Ricardo Ariel Gorosito 2000-10-12 11:23:50 EDT


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.


In main.c, function php3_log_error():

                if (!strcmp(php3_ini.error_log, "syslog")) {
                        syslog(LOG_NOTICE, log_message);
                } else {
                        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

The code fragments above are taken from PHP 3 sources, but the
vulnerabilities exist in PHP version 4 too.


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



Vulnerability discovered by: Jouko Pynnvnen <jouko@solutions.fi>
Comment 1 Arenas Belon, Carlo Marcelo 2000-10-17 04:09:45 EDT
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 09:29:59 EDT
php-4.0.3pl1 is broken too (at least the target_platform for building a DSO

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 09:34:24 EDT
Created attachment 4268 [details]
patch from the spec on php-4.0.2-2
Comment 4 Arenas Belon, Carlo Marcelo 2000-10-17 09:35:34 EDT
Created attachment 4269 [details]
-redhat patch for 4.0.3pl1 (configuration changes)
Comment 5 Nalin Dahyabhai 2000-10-17 17:51:19 EDT
An errata is already in the pipeline.

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