Hacker News Board Hacker News, browsed like a classic message board
Live data from Hacker News

PHP-FPM remote code execution bug exploited in the wild

github.com

Post reply on HN
Print view View original

11–20 of 139 posts

Re: PHP-FPM remote code execution bug exploited in the wild

#11

Post by cbg0 »

kgersen75 wrote: post #8
thesorrow wrote: post #5

I'm sure a lot of PHP 7.0 installations are still in production and will not receive a patch...

The issue is PHP-FPM (FastCGI) only and it's vulnerable from outside only with nginx. The vast majority of PHP 7.0 installations don't use FastGCI and don't use nginx but Apache simply because people used 'apt install php' (or 'yum install php') to install it. So imho, the impact is very limited.

> The vast majority of PHP 7.0 installations don't use FastGCI and don't use nginx

Do you have a source for this?

Re: PHP-FPM remote code execution bug exploited in the wild

#14

Post by tyingq »

jstanley wrote: post #12

The exploit requires > 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?

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

#15

Post by wolco »

cbg0 wrote: post #11
kgersen75 wrote: post #8

Earlier quoted context omitted.

The issue is PHP-FPM (FastCGI) only and it's vulnerable from outside only with nginx. The vast majority of PHP 7.0 installations don't use FastGCI and don't use nginx but Apache simply because people used 'apt install php' (or 'yum install php') to install it. So imho, the impact is very limited.

> The vast majority of PHP 7.0 installations don't use FastGCI and don't use nginx Do you have a source for this?

Common approach is to serve static files with nginx and use apache / php_mod to process.

Why are you running php-fpm? Do you need to separate request's processes? The speed benefits of php-fpm are part of php 7 so using php_mod is faster now.

Re: PHP-FPM remote code execution bug exploited in the wild

#18

Post by wolco »

kijin wrote: post #2

Ubuntu has a try_files directive in /etc/nginx/snippets/fastcgi-php.conf that is included by default. It was put there years ago to guard against another problem (also mentioned by OP), but it seems that the try_files directive will block this one, too. Unfortunately, too many people still copy & paste three-liners from random blogs and call it a day, often overwriting the safe defaults provided by their distro, er,…

CentOS isn't marketed as a desktop distro. The listening default is helpful and when I switched over to Ubuntu that default of not listening confused me. Not sure I see the benefit.. it's like installing windows but the internet is disabled by default and must be configured manually.. installing another browser and you must configure it manually.

Re: PHP-FPM remote code execution bug exploited in the wild

#19

Post by tomclancy »

jstanley wrote: post #12

The exploit requires > 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?

>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

#20

Post by lioeters »

kijin wrote: post #2

Ubuntu has a try_files directive in /etc/nginx/snippets/fastcgi-php.conf that is included by default. It was put there years ago to guard against another problem (also mentioned by OP), but it seems that the try_files directive will block this one, too. Unfortunately, too many people still copy & paste three-liners from random blogs and call it a day, often overwriting the safe defaults provided by their distro, er,…

I confirmed that Ubuntu's default config in /etc/nginx/snippets/fastcgi-php.conf has a try_files directive that prevents this exploit.
Post reply on HN