Bug 101608 - off-by-one bug in config directive parsing
Summary: off-by-one bug in config directive parsing
Alias: None
Product: Red Hat Linux
Classification: Retired
Component: php   
(Show other bugs)
Version: 9
Hardware: i386
OS: Linux
Target Milestone: ---
Assignee: Joe Orton
QA Contact: David Lawrence
Depends On:
TreeView+ depends on / blocked
Reported: 2003-08-04 17:22 UTC by Denice
Modified: 2007-04-18 16:56 UTC (History)
0 users

Fixed In Version:
Doc Type: Bug Fix
Doc Text:
Story Points: ---
Clone Of:
Last Closed: 2005-01-25 16:47:39 UTC
Type: ---
Regression: ---
Mount Type: ---
Documentation: ---
Verified Versions:
Category: ---
oVirt Team: ---
RHEL 7.3 requirements from Atomic Host:
Cloudforms Team: ---

Attachments (Terms of Use)
tgz file contains all (5.36 KB, application/octet-stream)
2003-08-04 17:47 UTC, Denice
no flags Details
fix for the off-by-one bug (8.20 KB, patch)
2003-08-05 09:25 UTC, Joe Orton
no flags Details | Diff

Description Denice 2003-08-04 17:22:11 UTC
From Bugzilla Helper:
User-Agent: Mozilla/5.0 (X11; U; Linux i686; en-US; rv:1.2.1) Gecko/20030225

Description of problem:
I am attaching a simple apache configuration and index.php file that
demonstrates random post variable corruption when inlined variable
'post_max_size' is set to something different in the apache configuration -- in
this case 30M.

The php script presents a small table of books.  You press a sort button at the
top of a column, and debug output says what the post variable is and what its
value is.  In normal behaviour you would only see the blue message saying how
the table was sorted.  But in the abnormal condition you would start seeing red
messages and garbage in the post variable after 10 or so random button presses.

It doesn't seem to matter much what the /etc/php.ini file contains.  However I
am attaching it too.

I cannot reproduce this problem on Severn (php 4.3.2). So there seems to be some
validity (at least for me) for the php people to warn about php and apache
before version 4.3:

Version-Release number of selected component (if applicable):
php-4.2.2-17.2, httpd-2.0.40-21.3

How reproducible:

Steps to Reproduce:
1. install my example httpd.conf into /etc/httpd/conf/, nonssl.conf into
2. copy index.php into /var/www/html/nonssl/
3. change the ip/hostname to something other than
   and start httpd

Actual Results:  corrupt post vars with any kind of garbage, including binary chars

Expected Results:  press the sort buttons until the cows come home, and never
see anything but blue messages.

Additional info:

Comment 1 Denice 2003-08-04 17:47:12 UTC
Created attachment 93379 [details]
tgz file contains all

files unpack into a dir named 'files/' (really original, eh?)

Comment 2 Joe Orton 2003-08-04 20:02:19 UTC
The configuration variable:

   php_admin_value post_max_size 30M

is being intepreted as 30 bytes rather than 30 megabytes.  I can't reproduce any
problems if I increase this to 300000 - can you try that?

Comment 3 Denice 2003-08-04 21:33:59 UTC
With the last patch for php at RH 9, this problem of 
   php_admin_value post_max_size 30M
being intepreted as 30 bytes rather than 30 megabytes __seemed_ to have went
away. At earlier patch levels I tripped across this problem with my 'real' web
pages, and quickly substituted 30000000 for 30M -- but still had problems.  I
could post hardly anything at the time _without_ tripping over this problem if
I left the value at 30M.  phpinfo() always showed '30' instead of 30M.

Anyway, with a RH 9 config today, the last patch and a test php script
containing the phpinfo() function, I saw 30M in the output. and thought the
problem gone.

However, I just tested with your suggestion.  All the way down to 5M, and
without testing further down, I have the problem of corrupted post vars.  But
*if* I substitute 5000000 then the problem goes away.  Yuck. It is troubling.
Either way, it's a bug..  At Severn the interpretation of xM seems correct with
my bit of testing.  Thanks for the quick response.

Comment 4 Denice 2003-08-04 22:09:46 UTC
It's late here, and damn hot; and I just read my post again.  I don't know if
it made any sense at all :-{   Anyway, let me try to be more clear.
There are/have-been 2 problems, I guess:
  - in the past I found that you absolutely had to say 30000000 instead of
    30M (for example) in the config file, or nothing worked.  It's a bug.
  - with the last RH 9 php patch, this problem _seemed_ to have disappeared.
    But still I had post-var corruption.  However, with my small test program,
    if I fall back to inserting 30000000 instead of 30M in the file as you
    suggested, then the post-var corruption disappears.  I would need to test
    my real web environment against this, and I will.  But it's still a bug.

However, mow I am wondering if I tested my real web trees adequately with 
both the 30M and 30000000 values.  It is easy to make a boo-boo when you
are trying to isolate the real bug...

I will try to do the rounds again with all these magnificent php-apache 
configuration directives, and see if I can scare up the remaining problem

It may seems wierd to some people, but these directives can come in -real- 
handy when you are migrating web trees with wildly different virtual hosts.
For example, in a move from apache1 to apache2, you would want to debug and
secure a web tree, and then move onto the next.  If you can give each virtual
host a wide-open config, and then gradually secure and test them, then you can 
proceed in an orderly fashion, and avoid the big-bang approach to web tree
migration.  Does that make any sense?

Comment 5 Joe Orton 2003-08-05 09:20:55 UTC
Yes, there is a simple off-by-one bug in PHP 4.2 which is causing these config
directives to be misinterpreted, it's fixed in PHP 4.3.  We'll backport the fix
for future 8.0/9 PHP errata.

Comment 6 Joe Orton 2003-08-05 09:25:39 UTC
Created attachment 93397 [details]
fix for the off-by-one bug

This is an updated copy of the php-4.2.2-apache2.patch from the PHP source RPM
which includes the fix for this off-by-one bug.

Comment 7 Joe Orton 2005-01-25 16:47:39 UTC
Thanks for the report.  This is a mass bug update; since this release
of Red Hat Linux is no longer supported, please either:

a) try and reproduce the bug with a supported version of Red Hat
Enterprise Linux or Fedora Core, and re-open this bug as appropriate
after changing the Product field, or,

b) if relevant, try and reproduce this bug using the current version
of the upstream package, and report the bug upstream.

c) report the bug to the Fedora Legacy project who may wish to
continue maintenance of this package.

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