php.net |  support |  documentation |  report a bug |  advanced search |  search howto |  statistics |  random bug |  login
Bug #79549 PHP-FPM sends invalid headers '0\xd5e\xc8' to the web server
Submitted: 2020-04-30 23:18 UTC Modified: 2020-05-01 20:08 UTC
From: morozov at tut dot by Assigned:
Status: Verified Package: opcache
PHP Version: 7.4.5 OS: Linux
Private report: No CVE-ID: None
Welcome back! If you're the original bug submitter, here's where you can edit the bug or add additional notes.
If this is not your bug, you can add a comment by following this link.
If this is your bug, but you forgot your password, you can retrieve your password here.
Password:
Status:
Package:
Bug Type:
Summary:
From: morozov at tut dot by
New email:
PHP Version: OS:

 

 [2020-04-30 23:18 UTC] morozov at tut dot by
Description:
------------
Under certain circumstances which I cannot currently isolate, PHP-FPM responds to the webserver (Apache) with certain invalid headers that result in a 500 response from apache.

The issue is only reproducible in a proprietary application. There are certain criteria I was able to identify which make the issue trigger. If I remove any of them, the issue goes away:

1. Opcache enabled.
2. header('Expires:'); header('Pragma:');  // note the absence of the value which is probably invalid. Sometimes the issue is also reproducible even w/o invalid headers
3. Response length. With all other parameters the same, a "[]" json response doesn't cause the issue but a valid 180-bytes response does.
4. Some seemingly unrelated function calls like file_get_contents().

Actual result:
--------------
Apache response:
<!DOCTYPE HTML PUBLIC "-//IETF//DTD HTML 2.0//EN">
<html><head>
<title>500 Internal Server Error</title>
</head><body>
<h1>Internal Server Error</h1>
<p>The server encountered an internal error or
misconfiguration and was unable to complete
your request.</p>
<p>Please contact the server administrator at 
 [no address given] to inform them of the time this error occurred,
 and the actions you performed just before this error.</p>
<p>More information about this error may be available
in the server error log.</p>
<p>Additionally, a 304 Not Modified
error was encountered while trying to use an ErrorDocument to handle the request.</p>
<hr>
<address>Apache/2.4.41 (Ubuntu) Server at sugarcrm.local Port 80</address>
</body></html>

Apache logs:

[Thu Apr 30 14:57:39.470700 2020] [http:error] [pid 73344:tid 140477684762368] [client 127.0.0.1:35104] AH02429: Response header name '0\xd5e\xc8' contains invalid characters, aborting request, referer: ...
[Thu Apr 30 14:57:39.725176 2020] [http:error] [pid 73311:tid 140478498461440] [client 127.0.0.1:35016] AH02429: Response header name '\x90\x84f\xc8' contains invalid characters, aborting request, referer: ...
[Thu Apr 30 15:06:12.065188 2020] [http:error] [pid 73344:tid 140478162917120] [client 127.0.0.1:39432] AH02429: Response header name '0\x85f\xc8' contains invalid characters, aborting request, referer: ...
[Thu Apr 30 15:14:17.448112 2020] [http:error] [pid 73344:tid 140478869321472] [client 127.0.0.1:43298] AH02429: Response header name 'p\x84f\xc8' contains invalid characters, aborting request, referer: ...
[Thu Apr 30 15:43:12.482083 2020] [http:error] [pid 73344:tid 140478877714176] [client 127.0.0.1:57656] AH02429: Response header name '@\x84f\xc8' contains invalid characters, aborting request, referer: ...
[Thu Apr 30 15:50:02.294075 2020] [http:error] [pid 73311:tid 140478246811392] [client 127.0.0.1:60500] AH02429: Response header name 'P\x84f\xc8' contains invalid characters, aborting request, referer: ...
[Thu Apr 30 15:50:05.837520 2020] [http:error] [pid 73311:tid 140478230025984] [client 127.0.0.1:33090] AH02429: Response header name ' \x84f\xc8' contains invalid characters, aborting request, referer: ...


Patches

Add a Patch

Pull Requests

Add a Pull Request

History

AllCommentsChangesGit/SVN commitsRelated reports
 [2020-05-01 00:59 UTC] requinix@php.net
-Summary: PHP-FPM sends wrong headers to the web server +Summary: PHP-FPM sends invalid headers '0\xd5e\xc8' to the web server
 [2020-05-01 00:59 UTC] requinix@php.net
Is there any way you can dump the full response from php-fpm to somewhere you can read it?
 [2020-05-01 01:35 UTC] morozov at tut dot by
What's the recommended way of intercepting traffic between a web server and PHP FPM? I use a local Unix socket for development. Should I switch to TCP/IP and use something like Wireshark?
 [2020-05-01 03:54 UTC] morozov at tut dot by
Please see the dump at https://gist.github.com/morozov/bfe35ea3298681cf75b6ba54d67d2575

Right before the empty Pragma: header there was supposed to be the Expires: one.
 [2020-05-01 04:20 UTC] requinix@php.net
-Status: Open +Status: Verified
 [2020-05-01 04:20 UTC] requinix@php.net
The important bit being

20:47:31.786 >>> process php-fpm [125706 -> 73344] len 152(152)
~Status: 304 Not Modified
X-Powered-By: PHP/7.4.5
Cache-Control: max-age=0, private
j
Pragma:
Content-Length: 2

ort

I've confirmed that whole thing is indeed 152 bytes.

You can take down the gist if you want, but just in case, please dump one of these outputs to a file and hang onto it in case it's useful.

So yeah, definitely screwy: there's leading garbage before the headers, clearly something weird happened to the Expires, and there's more garbage before the body.

Would you be able to try running on other PHP versions? I suggest 7.4.1 and a recent 7.3.


Separately, notice that this is a 304 but it comes with some output. If your application is responsible for emitting that (and given the Content-Length header I think it is), it's incorrect behavior that you should look into when you have the time.
 [2020-05-01 05:41 UTC] morozov at tut dot by
> Would you be able to try running on other PHP versions? I suggest 7.4.1 and a recent 7.3.

I tried 7.4.1 (also reproducible) and 7.3.17 (not reproducible). Please see the dumps in the updated gist.

> Separately, notice that this is a 304 but it comes with some output. If your application is responsible for emitting that (and given the Content-Length header I think it is), it's incorrect behavior that you should look into when you have the time.

Definitely. Thank you for pointing that out.
 [2020-05-01 20:08 UTC] morozov at tut dot by
> If your application is responsible for emitting that (and given the Content-Length header I think it is), it's incorrect behavior […]

FWIW, even with the issue fixed (no Content-* headers and body sent with a 304 response), the issue is still reproducible.
 
PHP Copyright © 2001-2020 The PHP Group
All rights reserved.
Last updated: Tue Nov 24 16:01:24 2020 UTC