Re:PHP-FPM remote code execution bug exploited in the wild
by tomclancy on Sunday October 27, 2019 @12:45PM
(#21370812)
>There must be a PATH_INFO variable assignment via statement fastcgi_param PATH_INFO $fastcgi_path_info;. At first, we thought it is always present in the fastcgi_params file, but it's not true.
This is also precondition, and fortunately it's not included in standard fastcgi_params files.
Re:PHP-FPM remote code execution bug exploited in the wild
by tyingq on Sunday October 27, 2019 @12:34PM
(#21370729)
I don't think you can fix it there, because you probably need stuff like /foo.php?key=value to work. (Edit: not quite...see comment below)
The try_files config mentioned on the page mitigates the issue.
Re:PHP-FPM remote code execution bug exploited in the wild
by makomk on Sunday October 27, 2019 @01:01PM
(#21370914)
I don't think this line is required to make foo.php?key=value to work, because the query parameters aren't treated as part of the path. It's for URLs like foo.php/bar where you have some path after the PHP file that's passed to the script - this was supported out the box by Apache mod_php and there's a fair amount of code out there that relies on it. (Generally because cleaner methods of feeding a set of paths to one PHP script require server configuration that may not be available on cheap shared web hosting.)
> fastcgi_split_path_info ^(.+?\.php)(/.*)$;
If I'm not using this feature of PHP, what can I put in this config value to prevent the exploit from working?