Bug #69322 [NEW]: LimitRequestBody excession not handled correctly
| From: | gmoniker at gmail dot com | Date: | Sat, 28 Mar 2015 22:56:24 +0000 |
| Subject: | Bug #69322 [NEW]: LimitRequestBody excession not handled correctly | ||
| Groups: | php.bugs | ||
| Request: | Send a blank email to php-bugs+get-191670@lists.php.net to get a copy of this message | ||
From: gmoniker at gmail dot com
Operating system: Ubuntu 14.04
PHP version: 5.6.7
Package: Apache2 related
Bug Type: Bug
Bug description:LimitRequestBody excession not handled correctly
Description:
------------
If you set a LimitRequestBody in the Apache configuration there are
unexpected results with the apache2 PHP module.
Expected: an excession of the LimitRequestBody should cancel the entire
handling of a PHP request. The script called should not run, and thus
produce no output. A PHP script configured to handle a 413 Error should
not accept the request body but be fully functional otherwise.
There are up to four parameters to this bug:
1. The original handler in use (The one Apache selects or first accepts
for handling the URI requested by the client.)
2. The ErrorDocument for 413. (Is it PHP or not)
3. The Apache version.
4. Whether the request is the first to PHP on a worker.
In Apache 2.2 (with PHP 5.3.10):
When you call a static html file handled by the core module, there is
only the output of the 413 ErrorDocument. Using PHP for the
ErrorDocument works correctly.
When you call a PHP script, you get first the output of the
ErrorDocument and then the output of the original PHP script. Using PHP
for the ErrorDocument works correctly.
In Apache 2.4 (with PHP 5.5.9)
When you call a static html file handled by the core module, there is
only the output of the 413 ErrorDocument. Using PHP for the
ErrorDocument works correctly.
When you call a PHP script, you get first the output of the
ErrorDocument and then the output of the original PHP script. If you
call this as the very first PHP call on a worker, the worker crashes
with segfault.
All tests done with apache prefork mpm and opcache off on 64-bit system.
Test script:
---------------
Needed: Apache with prefork mpm, PHP module for Apache, curl, 64-bit
system. For 32-bit system results unknown.
Set in Apache config:
LimitRequestBody 1000
ErrorDocument 413 "/error413.php"
In PHP config for Apache:
disable opcache
;zend_extension=opcache.so
Put a PHP script posterror.php with some output, an error413.php script
with some output, and index.html in a suitable documentroot.
Stop pre-running Apache webserver
Start Apache in different terminal: apache2ctl -X
printf '%*s' 2000 | sed 's/ /-/g' > body.txt
curl -si -F "post=@body.txt;filename=body.txt"
http://localhost/posterror.php
curl -si -F "post=@body.txt;filename=body.txt"
http://localhost/index.html
Expected result:
----------------
When Apache intercepts the call to a script with a 413 error, I expect
the PHP script not to run and thus produce no output, only the output of
the ErrorDocument if it exists together with a 413 Request Entity Too
Large response status.
In the case of Apache 2.4, I do not expect a difference between the
first call to PHP on a running Apache worker and subsequent calls.
Actual result:
--------------
Backtrace for segfault on first request to Apache 2.4 with a PHP script
and a PHP ErrorDocument for 413:
Program received signal SIGSEGV, Segmentation fault.
0x00007ffff3a086cc in php_session_rfc1867_callback (event=5,
event_data=0x7fffffffc700, extra=0x7fffffffc5d0)
at /root/php5-5.5.9+dfsg/ext/session/session.c:2747
2747 if (Z_TYPE(progress->sid) &&
progress->key.c) {
(gdb) bt
#0 0x00007ffff3a086cc in php_session_rfc1867_callback (event=5,
event_data=0x7fffffffc700,
extra=0x7fffffffc5d0) at
/root/php5-5.5.9+dfsg/ext/session/session.c:2747
#1 0x00007ffff3b8df6e in rfc1867_post_handler
(content_type_dup=0x7ffff7f26ff8 "\252~M\353R\006",
arg=0x7ffff7f29680) at /root/php5-5.5.9+dfsg/main/rfc1867.c:1260
#2 0x00007ffff3b88b73 in sapi_handle_post (arg=0x7ffff7f29680) at
/root/php5-5.5.9+dfsg/main/SAPI.c:189
#3 0x00007ffff3b90217 in php_default_treat_data (arg=0, str=0x0,
destArray=0x0)
at /root/php5-5.5.9+dfsg/main/php_variables.c:322
#4 0x00007ffff39a1a48 in mbstr_treat_data (arg=0, str=0x0,
destArray=0x0)
at /root/php5-5.5.9+dfsg/ext/mbstring/mb_gpc.c:69
#5 0x00007ffff3b913e2 in php_auto_globals_create_post
(name=0x7ffff13474a0 "_POST", name_len=5)
at /root/php5-5.5.9+dfsg/main/php_variables.c:665
#6 0x00007ffff3bf3d68 in zend_auto_global_init
(auto_global=0x555555818480)
at /root/php5-5.5.9+dfsg/Zend/zend_compile.c:6724
#7 0x00007ffff3c1f728 in zend_hash_apply (ht=0x555555803d80,
apply_func=0x7ffff3bf3d1c <zend_auto_global_init>) at
/root/php5-5.5.9+dfsg/Zend/zend_hash.c:716
#8 0x00007ffff3bf3da1 in zend_activate_auto_globals () at
/root/php5-5.5.9+dfsg/Zend/zend_compile.c:6734
#9 0x00007ffff3b91179 in php_hash_environment () at
/root/php5-5.5.9+dfsg/main/php_variables.c:625
#10 0x00007ffff3b7d34d in php_request_startup () at
/root/php5-5.5.9+dfsg/main/main.c:1595
#11 0x00007ffff3d50fd7 in php_apache_request_ctor (r=0x7ffff7e8a0a0,
ctx=0x7ffff7e864d0)
at /root/php5-5.5.9+dfsg/sapi/apache2handler/sapi_apache2.c:502
#12 0x00007ffff3d515f8 in php_handler (r=0x7ffff7e8a0a0)
at /root/php5-5.5.9+dfsg/sapi/apache2handler/sapi_apache2.c:618
#13 0x00005555555aa830 in ap_run_handler (r=0x7ffff7e8a0a0) at
config.c:169
#14 0x00005555555aad79 in ap_invoke_handler (r=r@entry=0x7ffff7e8a0a0)
at config.c:439
#15 0x00005555555c033a in ap_process_async_request (r=0x7ffff7e8a0a0) at
http_request.c:317
#16 0x00005555555c0614 in ap_process_request (r=r@entry=0x7ffff7e8a0a0)
at http_request.c:363
#17 0x00005555555bd0b2 in ap_process_http_sync_connection
(c=0x7ffff7e8e290) at http_core.c:190
#18 ap_process_http_connection (c=0x7ffff7e8e290) at http_core.c:231
#19 0x00005555555b3e70 in ap_run_process_connection (c=0x7ffff7e8e290)
at connection.c:41
#20 0x00005555555b4258 in ap_process_connection
(c=c@entry=0x7ffff7e8e290, csd=<optimized out>)
at connection.c:202
#21 0x00007ffff468a767 in child_main
(child_num_arg=child_num_arg@entry=0) at prefork.c:704
#22 0x00007ffff468a96c in make_child (s=0x7ffff7fc1de0,
slot=slot@entry=0) at prefork.c:746
#23 0x00007ffff468b6b1 in prefork_run (_pconf=<optimized out>,
plog=0x7ffff7fbd028, s=0x7ffff7fc1de0)
at prefork.c:956
#24 0x00005555555916de in ap_run_mpm (pconf=0x7ffff7ff0028,
plog=0x7ffff7fbd028, s=0x7ffff7fc1de0)
at mpm_common.c:96
#25 0x000055555558ae76 in main (argc=2, argv=0x7fffffffe658) at
main.c:777
--
Edit bug report at https://bugs.php.net/bug.php?id=69322&edit=1
--
Try a snapshot (PHP 5.4): https://bugs.php.net/fix.php?id=69322&r=trysnapshot54
Try a snapshot (PHP 5.5): https://bugs.php.net/fix.php?id=69322&r=trysnapshot55
Try a snapshot (trunk): https://bugs.php.net/fix.php?id=69322&r=trysnapshottrunk
Fixed in SVN: https://bugs.php.net/fix.php?id=69322&r=fixed
Fixed in release: https://bugs.php.net/fix.php?id=69322&r=alreadyfixed
Need backtrace: https://bugs.php.net/fix.php?id=69322&r=needtrace
Need Reproduce Script: https://bugs.php.net/fix.php?id=69322&r=needscript
Try newer version: https://bugs.php.net/fix.php?id=69322&r=oldversion
Not developer issue: https://bugs.php.net/fix.php?id=69322&r=support
Expected behavior: https://bugs.php.net/fix.php?id=69322&r=notwrong
Not enough info: https://bugs.php.net/fix.php?id=69322&r=notenoughinfo
Submitted twice: https://bugs.php.net/fix.php?id=69322&r=submittedtwice
register_globals: https://bugs.php.net/fix.php?id=69322&r=globals
PHP 4 support discontinued: https://bugs.php.net/fix.php?id=69322&r=php4
Daylight Savings: https://bugs.php.net/fix.php?id=69322&r=dst
IIS Stability: https://bugs.php.net/fix.php?id=69322&r=isapi
Install GNU Sed: https://bugs.php.net/fix.php?id=69322&r=gnused
Floating point limitations: https://bugs.php.net/fix.php?id=69322&r=float
No Zend Extensions: https://bugs.php.net/fix.php?id=69322&r=nozend
MySQL Configuration Error: https://bugs.php.net/fix.php?id=69322&r=mysqlcfg