Live data from Hacker News

PHP-FPM remote code execution bug exploited in the wild

github.com

61–70 of 139 posts

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

#61
post #49

Earlier quoted context omitted.

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

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

Sure, but the price of not having 24/7 support may be that instead of applying a patch you get to nuke everything from orbit and rebuild from backups.

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

#62
post #53

Earlier quoted context omitted.

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).

Get a wildcard

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

#63
post #49
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.

[deleted]

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

#64
I have that location block in my nginx config but I also have the following above:

    location / {
        try_files $uri $uri/ /index.php?$query_string;
    }
Does this mean I'm safe? I'm asking because it's in a separate location block so not sure how this works (thinking that the try_files thing should be in the same location block).

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

#65

Earlier quoted context omitted.

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

Sure, but the price of not having 24/7 support may be that instead of applying a patch you get to nuke everything from orbit and rebuild from backups.

Sure, but just because the company didn't want to shell out the dough for 24/7 support doesn't mean that the employees should necessarily take it upon themselves to work during their off time.

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

#66
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…

If i read the commit fixing the vulnerability correctly, you need to have env PATH_INFO set; SCRIPT_FILENAME is unaffected. I would expect other reverse proxies strip newline characters and such from the url, but YMMV. In the bug tracker someone suggested adding an url rewrite that strips away \n and anything that follows. That might be a viable mitigation for versions no longer patched.

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

#67

Earlier quoted context omitted.

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

Sure, but the price of not having 24/7 support may be that instead of applying a patch you get to nuke everything from orbit and rebuild from backups.

Eh, as long as the database is intact, just nuke the container, rebuild base image and you're free.

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

#68

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...

I wish there was a webdav server that wasn't a huge PHP thing and had decent authentication/authorization.

Almost everything has SFTP built in anyway now though, it's only a matter of time before OSes other than Linux based ones integrate it into the shells and then webdav won't matter so much.

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

#69
post #53

Earlier quoted context omitted.

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).

TLS hides the path from a potential attacker that could observe traffic. Putting your nextcloud instance on a nonstandard path might help in this case, but - if I read the issue correctly - not in this cases

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

#70

Earlier quoted context omitted.

Sure, but the price of not having 24/7 support may be that instead of applying a patch you get to nuke everything from orbit and rebuild from backups.

Sure, but just because the company didn't want to shell out the dough for 24/7 support doesn't mean that the employees should necessarily take it upon themselves to work during their off time.

It probably comes down to the environment for other work. If the company will "pay the price" then that's okay, but if you will "pay the price" i.e. if a need to nuke everything from orbit and rebuild from backup will simply result in a lot of unpaid overtime for you, that sucks, but in that case you might prefer to do less unpaid work in your off time today instead of more unpaid work in your off time throughout the next week.
Post reply on HN