SAPI apache2handler + pipelined HTTP request core dumps

9 years ago by Patrick Schaaf — view source

unread

Dear internals,

can somebody knowledgeable about the apache2handler code, please have a look
at the following bug report?

https://bugs.php.net/bug.php?id=68486

I just added a comment with a hotfix that appears to work at first glance, but
I'm completely unsure whether that will result in memory leaks or other
problems.

best regards
Patrick

9 years ago by Patrick Schaaf — view source

unread

On Tuesday 10 March 2015 10:26:12 Patrick Schaaf wrote:

https://bugs.php.net/bug.php?id=68486

Meanwhile I did some more debugging, today also testing with a freshly
compiled current apache 2.4.12. The issue persists.

As it does not always coredump, but always uncontrollably reenters an already-
deconfigured PHP interpreter, I see the potential for arbitrary remote code
execution. I opened a security bug for that two days ago - no reaction.

Sorry for shouting, BUT IS REALLY NOBODY HERE INTERESTED IN (non-fpm) PHP
UNDER APACHE 2.4 / LINUX ??????

I don't want to go out on the internet and test whether I can randomly crash
any such server, but everything I analyzed so far tells me that half of the
world might be affected by this.

For those who cannot be bothered to read the bug report, but have an apache
2.4 running with mod_php, could you please run the following against your
server, and look for segmentation violation / coredump messages in your server
logs?

echo -e 'GET /foo.php HTTP/1.1\nHost: www.example.de\n\nGET /foo.php
HTTP/1.1\nHost: www.example.de\n\n' | nc localhost 80

(of course, replace /foo.php with any trivial PHP script on your server, and
www.example.de with your virtual host name)

best regards
Patrick

P.S.: to anybody who now wants to tell me to just use FPM/fastCGI: save the
bits, I don't want to hear that.

9 years ago by Bostjan Skufca — view source

unread

I can confirm the behaviour. Even if I do not change script names and/or
HTTP host.

On Tuesday 10 March 2015 10:26:12 Patrick Schaaf wrote:

https://bugs.php.net/bug.php?id=68486

Meanwhile I did some more debugging, today also testing with a freshly
compiled current apache 2.4.12. The issue persists.

As it does not always coredump, but always uncontrollably reenters an
already-
deconfigured PHP interpreter, I see the potential for arbitrary remote code
execution. I opened a security bug for that two days ago - no reaction.

Sorry for shouting, BUT IS REALLY NOBODY HERE INTERESTED IN (non-fpm) PHP
UNDER APACHE 2.4 / LINUX ??????

I don't want to go out on the internet and test whether I can randomly
crash
any such server, but everything I analyzed so far tells me that half of the
world might be affected by this.

For those who cannot be bothered to read the bug report, but have an apache
2.4 running with mod_php, could you please run the following against your
server, and look for segmentation violation / coredump messages in your
server
logs?

echo -e 'GET /foo.php HTTP/1.1\nHost: www.example.de\n\nGET /foo.php
HTTP/1.1\nHost: www.example.de\n\n' | nc localhost 80

(of course, replace /foo.php with any trivial PHP script on your server,
and
www.example.de with your virtual host name)

best regards
Patrick

P.S.: to anybody who now wants to tell me to just use FPM/fastCGI: save the
bits, I don't want to hear that.

9 years ago by Jan Ehrhardt — view source

unread

Patrick Schaaf in php.internals (Tue, 10 Mar 2015 10:26:12 +0100):

Dear internals,

can somebody knowledgeable about the apache2handler code, please have a look
at the following bug report?

https://bugs.php.net/bug.php?id=68486

echo -e "GET /test.php HTTP/1.1\nHost: localhost\n\n
GET /test.php HTTP/1.1\nHost: localhost\n\n"|nc localhost 80

Are you running opcache? I tried to reproduce the bug on a Centos6 box,
Apache 2.4.12 with PHP 5.5.22 as mod_php and got a 'zend_mm_heap
corrupted' error when test.php contained phpinfo();

Bad enough, but no segfault.

When test.php contained nothing more than '<html>Apache is functioning
normally.</html>' there were no errors at all.

Jan

9 years ago by Bostjan Skufca — view source

unread

For me PHP 5.5.20 works OK, but PHP 5.6.6 segfaults.

Patrick Schaaf in php.internals (Tue, 10 Mar 2015 10:26:12 +0100):

Dear internals,

can somebody knowledgeable about the apache2handler code, please have a
look
at the following bug report?

https://bugs.php.net/bug.php?id=68486

echo -e "GET /test.php HTTP/1.1\nHost: localhost\n\n
GET /test.php HTTP/1.1\nHost: localhost\n\n"|nc localhost 80

Are you running opcache? I tried to reproduce the bug on a Centos6 box,
Apache 2.4.12 with PHP 5.5.22 as mod_php and got a 'zend_mm_heap
corrupted' error when test.php contained phpinfo();

Bad enough, but no segfault.

When test.php contained nothing more than '<html>Apache is functioning
normally.</html>' there were no errors at all.

Jan

9 years ago by Jan Ehrhardt — view source

unread

Bostjan Skufca in php.internals (Fri, 13 Mar 2015 18:20:55 +0100):

For me PHP 5.5.20 works OK, but PHP 5.6.6 segfaults.

OK (or rather not OK), I upgraded to 5.6.6:

echo -e "GET /index.php HTTP/1.1\nHost: localhost\n\n
GET /index.php HTTP/1.1\nHost: localhost\n\n"|nc localhost 80

index.php contains no PHP only 45 bytes html.

[Fri Mar 13 18:35:15.309433 2015] [core:notice] [pid 28551] AH00052:
child pid 28829 exit signal Segmentation fault (11)

This is with or without opcache.

Jan

9 years ago by Patrick Schaaf — view source

unread

Possible patch for the issue at

https://gist.github.com/bof/15173c7a11cb12a7b96f

with an explanatory comment in the bug report
https://bugs.php.net/bug.php?id=68486 at [2015-03-14 10:34 UTC]

Have a nice weekend
Patrick

9 years ago by Patrick Schaaf — view source

unread

Respin of my patch for https://bugs.php.net/bug.php?id=68486 is now available
as a gist here:

https://gist.github.com/bof/15173c7a11cb12a7b96f

Some comments on the respin are in the bug report at [2015-03-15 10:17 UTC]

Debug cruft has been removed, and as far as my brain can make out this is now
something that might just survive in production :) so please test....

best regards
Patrick

9 years ago by Patrick Schaaf — view source

unread

Am 15.03.2015 11:20 schrieb "Patrick Schaaf" php@bof.de:

Respin of my patch for https://bugs.php.net/bug.php?id=68486 is now
available
as a gist here:

https://gist.github.com/bof/15173c7a11cb12a7b96f

Some comments on the respin are in the bug report at [2015-03-15 10:17
UTC]

Debug cruft has been removed, and as far as my brain can make out this is
now
something that might just survive in production :) so please test....

To be explicit, I did NOT test

any apache worker except prefork
any kind of threadsafe build
any other OS than Linux (opensuse 13.1 + 11.4)
any other PHP than 5.6.7RC1

Patrick

9 years ago by Patrick Schaaf — view source

unread

Am 13.03.2015 18:18 schrieb "Jan Ehrhardt" phpdev@ehrhardt.nl:

https://bugs.php.net/bug.php?id=68486

echo -e "GET /test.php HTTP/1.1\nHost: localhost\n\n
GET /test.php HTTP/1.1\nHost: localhost\n\n"|nc localhost 80

Are you running opcache? I tried to reproduce the bug on a Centos6 box,
Apache 2.4.12 with PHP 5.5.22 as mod_php and got a 'zend_mm_heap
corrupted' error when test.php contained phpinfo();

Bad enough, but no segfault.

Happens with or without opcache, tried both lots of times.

The exact point of crashing is different depending on compiler
optimizations, opcache-or-not, and maybe other influences. (I tested also
with PHP compiled with both GCC 4.8, 4.9, and all levels of optimization,
while investigating, because I first thought it might be coming from one of
those influences)

The issue is definitely the apache/sapi_apache2 interaction. I know exactly
what goes wrong (see the comments in the bug report); I'm just not sure
what the all-encompassing fix would be, because I don't know what
situations the parent_req / reentrancy parts of the code are trying to
handle.

best regards
Patrick

9 years ago by Patrick Schaaf — view source

unread

Am 13.03.2015 18:26 schrieb "Bostjan Skufca" bostjan@a2o.si:

If we create unconditional php_server_context_cleanup() call at the
beginning of php_request(), would that be out of order? Does it remove also
all context-dependent configuration?

That's exactly what my Minipatch (addition of "1 ||") is doing.

The php_server_context_cleanup() does exactly one thing: set
SG(server_context) to NULL. My minipatch makes the code basically ignore
that in php_handler().

The problem I have is that I do not understand under which circumstances
that other codepath would be needed, which attempts to run a subrequest in
an already established and still active interpreter. The code must be there
for a reason, but I don't know it...

best regards
Patrick