PHP :: Bug #79549 :: PHP-FPM sends invalid headers '0\xd5e\xc8' to the web server

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

Votes:	2
Avg. Score:	3.0 ± 0.0
Reproduced:	1 of 1 (100.0%)
Same Version:	0 (0.0%)
Same OS:	0 (0.0%)

From:

morozov at tut dot by

Assigned:

Status:

Verified

Package:

opcache

PHP Version:

7.4.5

OS:

Linux

Private report:

CVE-ID:

None

View Developer Edit

[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

Pull Requests

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 01:44 UTC] requinix@php.net

I don't know, haven't done it before myself. Some quick leads for you to follow:
https://github.com/mechpen/sockdump
https://superuser.com/questions/484671/can-i-monitor-a-local-unix-domain-socket-like-tcpdump
https://superuser.com/questions/23180/whats-the-easiest-way-to-sniff-tcp-traffic-data-on-linux

[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.net \| support \| documentation \| report a bug \| advanced search \| search howto \| statistics \| random bug \| login
go to bug id or search bugs for


Copyright © 2001-2024 The PHP Group All rights reserved.	Last updated: Sat Dec 21 12:01:31 2024 UTC