php.net |  support |  documentation |  report a bug |  advanced search |  search howto |  statistics |  random bug |  login

go to bug id or search bugs for

Sec Bug #69218 potential remote code execution with apache 2.4 apache2handler
Submitted: 2015-03-11 09:17 UTC Modified: 2015-04-17 20:54 UTC
From: php at bof dot de Assigned: stas (profile)
Status: Closed Package: Apache2 related
PHP Version: 5.6.7RC1 OS: linux
Private report: No CVE-ID: 2015-3330
View Developer Edit
Welcome back! If you're the original bug submitter, here's where you can edit the bug or add additional notes.
If you forgot your password, you can retrieve your password here.
Password:
Status:
Package:
Bug Type:
Summary:
From: php at bof dot de
New email:
PHP Version: OS:

 

 [2015-03-11 09:17 UTC] php at bof dot de 
Description:
------------
Dear PHP security folks,

I'm investigating https://bugs.php.net/bug.php?id=68486 at the moment, and now think that it has the potential of resulting in remote code execution (at the machine code level, not PHP code level).

The issue is with Apache 2.4, the PHP apache2handler SAPI, and pipelined HTTP requests. Given a simple (just a single echo) PHP script http://example.com/foo the following results in segfaults, but not always:

echo -e "GET /foo HTTP/1.1\nHost: example.com\n\nGET /foo HTTP/1.1\nHost: example.com\n\n" | netcat localhost 80

This is because after the first request, the interpreter is deinitialized (sapi_apache2.c line 679 calls php_apache_request_dtor), BUT contrary to the situation under Apache 2.2, Apache 2.4 does NOT call the pool cleanup function (php_server_context_cleanup) before the second request is processed - resulting in SG(server_context) still being non-NULL, which then makes the second request being handled as a subrequest (parent_req != NULL), skipping the call to php_apache_request_ctor - thus running the request in a deconfigured interpreter.

Sometimes this leads to SEGV, sometimes it does not, which makes me fear this has the potential for RCE. I'm not a security researcher, just a lowly sysadmin, so I will not investigate exploitation potential further - but maybe you could?

Patches

Pull Requests

History

AllCommentsChangesGit/SVN commitsRelated reports
 [2015-03-16 16:03 UTC] php at bof dot de 
Hello? Anybody? I the original bug report, and on internals, we now have several positive reproducers for this issue. I worked on a fix, also see the original report.

From everything I understand so far:

EVERY apache2handler based Apache 2.4 ON THIS PLANET CAN BE MADE TO DUMP CORE or worse, AT WILL, WITH AN EASY DOUBLE-HTTP/1.1 REQUEST.

I will continue to work on my patch in the original report, without stressing the security implications too much; tomorrow I'll see that I can run my patched 5.6.7RC1 with our full production load, and will give feedback then.

Apart from that, I cannot invest much more time on this, especially without further guidance regarding several use case issues I don't understand with the current handler code.

Please also refer to these two internals list threads regarding discussion, reproductions, and open questions and issues:

        SAPI apache2handler + pipelined HTTP request core dumps
and, started today on a related topic
        PHP apache2handler virtual() function

Please tell, how would you like to proceed with this issue?
 [2015-03-17 20:52 UTC] stas@php.net 
Looks like the core issue is 68486, so I propose to keep the discussion there. It sounds like 2.4 subtly broke its own API without letting people know, but I guess we have to deal with it anyway. Unfortunately, I don't know apache2 internals enough to quickly evaluate this patch, so it probably will have to wait for the next release round, but I'll send a ping to people that may know more on it, and try to look into it a bit later.
 [2015-03-18 10:35 UTC] php at bof dot de 
Hi stas,

Apache 2.4 "broke" its API in the sense that the r->pool cleanup now happens asynchronously with request processing - sending of reply data to the client runs in parallel with processing the next request (of a HTTP/1.1 pipelined connection, at least), with the first request's r->pool cleanup only being called once all pending data has been sent to the client.

In https://bugs.php.net/bug.php?id=68486 gmoniker proposed a one-line fix to this, which appears to work in first testing. I'm giving it a workout on one of my production servers now, no coredumps during the first 10 minutes. I'll let that run for another 4 hours, and when it stays stable I'll add the one-line fix as a patch comment to the original ticket.
 [2015-03-19 08:31 UTC] php at bof dot de 
One-line patch for the issue is now attached to the original bug report. Production test with both apache 2.2 and 2.4 (prefork) has been running without any issues, since yesterday afternoon.

Stas, can you please take over getting this released? Maybe it would be good to make a CVE / some kind of advisory, once the fix is release, so people who have this deployed on apache 2.4 know they should upgrade?
 [2015-03-19 17:28 UTC] stas@php.net 
Does this patch work fine with virtual(), etc., esp. when virtual also calls PHP? Previous one had compatibility issues with that as I understand.
 [2015-03-19 18:59 UTC] php at bof dot de 
The one-liner patch fixes the remotely triggerable apache 2.4 http/1.1 pipelined connection segmentation fault.

virtual() is broken regardless of apache version, leading to a segmentation violation when reentering PHP. I verified this with apache 2.4 and 2.2 with PHP 5.6.7RC1, and just tested too with an old PHP 5.5.18 build under apache 2.2 - always segfaults.

That virtual() issue is clearly separate. I will keep investigating that a bit, and to that end open a new bug ticket - but as it seems to be a very old issue, and is not triggerable arbitrarily-remotely, I don't think it should be mixed with the fixing of bug 68486
 [2015-04-14 07:29 UTC] stas@php.net 
Automatic comment on behalf of stas
Revision: http://git.php.net/?p=php-src.git;a=commit;h=809610f5ea38a83b284e1125d1fff129bdd615e7
Log: Fix bug #68486 and bug #69218 (segfault in apache2handler with apache 2.4)
 [2015-04-14 08:31 UTC] stas@php.net 
Automatic comment on behalf of stas
Revision: http://git.php.net/?p=php-src.git;a=commit;h=809610f5ea38a83b284e1125d1fff129bdd615e7
Log: Fix bug #68486 and bug #69218 (segfault in apache2handler with apache 2.4)
 [2015-04-14 08:31 UTC] stas@php.net 
Automatic comment on behalf of stas
Revision: http://git.php.net/?p=php-src.git;a=commit;h=af1cd45d171fbb06712f846cec7bf69438db8ec2
Log: Fix bug #68486 and bug #69218 (segfault in apache2handler with apache 2.4)
 [2015-04-15 08:43 UTC] jpauli@php.net 
Automatic comment on behalf of stas
Revision: http://git.php.net/?p=php-src.git;a=commit;h=01883bcffb682f34309f9fbf112eecb050559522
Log: Fix bug #68486 and bug #69218 (segfault in apache2handler with apache 2.4)
 [2015-04-16 20:34 UTC] stas@php.net
-Status: Open +Status: Closed -Assigned To: +Assigned To: stas
 [2015-04-16 20:34 UTC] stas@php.net 
The fix for this bug has been committed.

Snapshots of the sources are packaged every three hours; this change
will be in the next snapshot. You can grab the snapshot at
http://snaps.php.net/.

 For Windows:

http://windows.php.net/snapshots/
 
Thank you for the report, and for helping us make PHP better.
 [2015-04-17 20:54 UTC] stas@php.net
-CVE-ID: +CVE-ID: 2015-3330
 
PHP Copyright © 2001-2024 The PHP Group
All rights reserved. 		Last updated: Thu Nov 21 14:01:29 2024 UTC