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

51–60 of 139 posts

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

#51

Post by heavyset_go »

UnoriginalGuy wrote: post #50
heavyset_go wrote: post #41

Earlier quoted context omitted.

This is a case study in why you shouldn't expose your self-hosted services to the internet.

Google has gone the opposite direction. I feel like throwing everything behind a VPN and pretending it is secure is a crux. Several famous break-ins over the last ten years have hypothetically been on the inside of that wall. Better to isolate services from each other limiting cross service jumping, than to build security around a single point of failure.

Security is in layers, there's no reason you can't rely on both service and network isolation.

Service isolation alone doesn't help when my private data is potentially exposed by this exploit.

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

#52

Post by oarsinsync »

UnoriginalGuy wrote: post #50
heavyset_go wrote: post #41

Earlier quoted context omitted.

This is a case study in why you shouldn't expose your self-hosted services to the internet.

Google has gone the opposite direction. I feel like throwing everything behind a VPN and pretending it is secure is a crux. Several famous break-ins over the last ten years have hypothetically been on the inside of that wall. Better to isolate services from each other limiting cross service jumping, than to build security around a single point of failure.

> Better to isolate services from each other limiting cross service jumping, than to build security around a single point of failure

I agree that it is better, but let’s not forget that building security around a single point of failure is still an improvement, that is simultaneously both high and low friction.

Bad: everything exposed to the internet

Good: everything behind a VPN

Best: Every application on its own micro-segment with access control up to the application layer to restrict all forms of access beyond the bare minimum of what is required.

Perfect is the enemy of good.

> Google has gone the opposite direction

Google scale solutions are great for google scale organisations. They don’t always scale down very well.

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

#53

Post by antocv »

kuzimoto wrote: post #45
heavyset_go wrote: post #41

Earlier quoted context omitted.

This is a case study in why you shouldn't expose your self-hosted services to the internet.

I have been thinking about this a lot lately. What is the best alternative, only accessing your services through a VPN?

I hide mine behind letsencrypt, just dont put nextcloud.yourdomain.com but put it under a path like yourdomain.com/shortPhrase/nextcloud where shortPhrase is something like noway pizde and so on.

Then dont share your links publicly.

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

#54

Post by nucleardog »

Does anyone know if this exploit has any lasting effects?

    After this, you can start appending ?a= to all PHP scripts (you may need multiple retries).
I'd love some way to confirm that my mitigations have worked and that I am no longer vulnerable but, y'know, running random slavic exploits against the server seems a bit sketchy.

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

#55

Post by nominated1 »

heavyset_go wrote: post #41
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...

This is a case study in why you shouldn't expose your self-hosted services to the internet.

It’s more evidence that you should assume everything is vulnerable and layer protection.

For a home network simple multi-port knocking should be enough (combined with --ctstate NEW even better). If port knocking or SPA is too cumbersome then at least consider limiting access based on GeoIP, block tor exit nodes, etc (ipset is pretty amazing).

This can be applied to any service on your network btw, including Wireguard. I like knowing that a portscan of my network shows nothing open. I don’t end up on a list that gets used in the next ‘spray and pray’ attack.

Disclaimer: I’m not advocating this for serious use due to replay attacks and IP spoofing via a VPS. This is for home network protection (a boring Class C non target).

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

#56

Post by organsnyder »

antocv wrote: post #53
kuzimoto wrote: post #45

Earlier quoted context omitted.

I have been thinking about this a lot lately. What is the best alternative, only accessing your services through a VPN?

I hide mine behind letsencrypt, just dont put nextcloud.yourdomain.com but put it under a path like yourdomain.com/shortPhrase/nextcloud where shortPhrase is something like noway pizde and so on. Then dont share your links publicly.

How does Let's Encrypt "hide" anything? Quite the contrary—the list of certs granted is publicly available (as it is for all CAs, I believe).

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

#57

Post by root_axis »

mantoto wrote: post #49
tetha wrote: post #44

Hmm, so looking at the exploit and the patch... do I read it right: There is a buffer underflow in php-fpm if the environment variables SCRIPT_FILENAME and PATH_INFO have a state that violates an assumption. And currently a widespread configuration of nginx + php-fpm is configured such that the URL can be suffiently mangled such that nginx sets these parameters in a violating manner. However, that means anything util…

On Monday? Assume your systems are compromised and act accordingly.

Some people choose not to work on weekends. Work/life balance etc.

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

#58

Post by thinkingemote »

oefrha wrote: post #9
kijin wrote: post #7

Earlier quoted context omitted.

They will receive a patch if they're using it on a Linux distro that is still supported (e.g. Ubuntu 16.04 LTS). How many people actually bother to run apt-get update && apt-get upgrade on their cloud servers or docker images is a different question, though.

Probably a good idea to auto install security updates. At least that’s what I do on my servers.

I think it's the default for several years now but I imagine it's not normal for a security update in PHP to restart an nginx process? Maybe it is.

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

#59

Post by samus »

oarsinsync wrote: post #52
UnoriginalGuy wrote: post #50

Earlier quoted context omitted.

Google has gone the opposite direction. I feel like throwing everything behind a VPN and pretending it is secure is a crux. Several famous break-ins over the last ten years have hypothetically been on the inside of that wall. Better to isolate services from each other limiting cross service jumping, than to build security around a single point of failure.

> Better to isolate services from each other limiting cross service jumping, than to build security around a single point of failure I agree that it is better, but let’s not forget that building security around a single point of failure is still an improvement, that is simultaneously both high and low friction. Bad: everything exposed to the internet Good: everything behind a VPN Best: Every application on its own mi…

> Every application on its own micro-segment with access control up to the application layer to restrict all forms of access beyond the bare minimum of what is required.

I hope for the operator team that they have good tool support to help administer all the access controls. Over time and across large organisations there are going to be a lot.

The even larger challenge must be auditing all these access controls. Services change, and if a connection is not required anymore, it should be painless for its operators to get rid of the corresponding access control.

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

#60

Post by NightlyDev »

maxymajzr wrote: post #43
wolco wrote: post #30

Earlier quoted context omitted.

Speed mostly.

Can you elaborate? I've yet to see Apache + mod_php to be capable of coming even close to + PHP-FPM so I'm really interested in what you guys are doing.

Mod_php was always faster at executing scripts. There is less overhead as you don't have to communicate like you have to with fpm.

For light scripts this is far superior to fpm. On the other hand, always loading php does have it's downsides too as memory consumption can get quite high depending on the number of threads.

This is was also the reason for the fpm hype a long time ago: don't waste memory on php when php isn't needed. It had nothing to do with it running php faster.

What you should choose depends on your need.

Post reply on HN