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

31–40 of 139 posts

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

#31

Post by wolco »

cbg0 wrote: post #24
wolco wrote: post #15

Earlier quoted context omitted.

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.

> Common approach is to serve static files with nginx and use apache / php_mod to process. Not sure how common that really is, I've personally never set things up like that and just use nginx + php-fpm and don't know anyone that still uses apache with mod_php.

We went from php_mod to php-fpm but we started moving back to php_mod after php 7 came out showing the benchmarks.

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

#32

Post by stephenr »

wolco wrote: post #30
stephenr wrote: post #27

Earlier quoted context omitted.

Why are you not running php-fpm with Apache is a more pressing question IMO.

Speed mostly.

I was under the impression that a properly tuned mpm_event and fpm has very little difference to mpm_prefork and mod_php. What sort of machines are you running this on and what sort of child proc numbers are you running?

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

#34

Post by ralala »

thesorrow wrote: post #17

FYI : If you have a NextCloud or Owncloud installation. The recommended nginx configuration is vulnerable [1] [1] https://nextcloud.com/blog/urgent-security-issue-in-nginx-ph...

The production-fpm docker image has not yet received any updates - correct?

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

#35

Post by gsmith2 »

As good a time as any to be reminded.. if you have to run any kind of PHP app, always keep it in its own VM and preferably with no access to anything except its own databases, and ideally with minimal outbound Internet access.

PHP security has improved markedly over time (especially app security, not just the runtime), but it's still.. well.. stuff like this. This time around I'm lucky that the sole app I run was using Apache

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

#36

Post by denton-scratch »

My job used to include writing PHP webpages that were exposed to the internet, and looking after the webservers they were running on.

I'm, not responsible for any public-facing webservers any more. My life is much better.

[Edit: I reckon using a well-designed functional language might reduce the risk - like, PHP was never designed at all, it grew by accretion]

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

#37

Post by larzang »

wolco wrote: post #31
cbg0 wrote: post #24

Earlier quoted context omitted.

> Common approach is to serve static files with nginx and use apache / php_mod to process. Not sure how common that really is, I've personally never set things up like that and just use nginx + php-fpm and don't know anyone that still uses apache with mod_php.

We went from php_mod to php-fpm but we started moving back to php_mod after php 7 came out showing the benchmarks.

That's true for us as well with our legacy applications.

Our newer applications are using litespeed instead, and we've found it to be significantly better. You basically get the features of a nginx + apache + varnish stack in a single easily managed service and with better performance too.

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

#40

Post by antocv »

denton-scratch wrote: post #36

My job used to include writing PHP webpages that were exposed to the internet, and looking after the webservers they were running on. I'm, not responsible for any public-facing webservers any more. My life is much better. [Edit: I reckon using a well-designed functional language might reduce the risk - like, PHP was never designed at all, it grew by accretion]

If anyone is following standard "recommended" practice, like in Nextcloud case, they get burned. This is true for all languages and frameworks.

If you dont practice defense-in-depth, you get rekt eventually.

I just checked my installation, its safe, since I didnt follow their "recommended" settings at all.

Since its a PHP app, what I do is put an extra nginx proxy infront of it, so there is nginx 1 (this one runs in its own lxc container with seccomp and has not even a /bin/sh in it, only executables and libc required for nginx, its only a network reverse proxy) - nginx2 (special instance for each php app, also same as nginx1 container with _nothing_ in it, but also a bind mounted ipc_socket which is also mounted to php_app container.

So the php_app container and nginx2 share only 1 ipc.socket bind mounted from the host. Now then, in the php app container, there is also lack of /bin/sh or anything else, not even the package manager, only what php-fpm requires, and the nextcloud .php scripts, are in there. _nothing_ else.

So even if this exploit would have worked, there would still be nothing standard to run in the php-app container (like /bin/ls), except the php scripts themselves, though thats bad enought to steal my nextcloud data.

Post reply on HN