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

131–139 of 139 posts

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

#131

Post by stephenr »

g8oz wrote: post #130
mtbcoder wrote: post #123

Earlier quoted context omitted.

> 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. The "overhead" of communicating via CGI to a PHP process has nothing to do with the speed of execution of the script itself. > 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 depen…

Yes CGI just allows you to scale in a way mod_php doesn't. Apache & mod_fcgid are a great combo imo.

Have you tried mod_proxy_fcgi? Being able to have similar handling for fpm and other proxied appservers (eg ruby or python stuff) is quite handy.

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

#132

Post by heavyset_go »

cyphar wrote: post #128
heavyset_go wrote: post #125

Earlier quoted context omitted.

> The problem with a VPN is that it makes it much harder to get friends and family to use it. Not to mention if you use the link sharing feature of NextCloud, you can't just give strangers VPN access. This is a feature. Besides, you can send friends and family a QR code to connect to your WireGuard VPN. It isn't perfect, but it beats having your personal data stolen.

I don't see how "you cannot use the link sharing feature of NextCloud" is a feature? Seems to be the precise opposite. As for setting everyone else up on the VPN, you could probably get that to work (you'd need to mess with DNS, AllowedIPs, and iptables rules to only allow port 443 access for your family's clients). I might look into that.

It's a security trade off, if an arbitrary person can't access your Nextcloud instance, neither can an attacker.

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

#133

Post by cyphar »

heavyset_go wrote: post #132
cyphar wrote: post #128

Earlier quoted context omitted.

I don't see how "you cannot use the link sharing feature of NextCloud" is a feature? Seems to be the precise opposite. As for setting everyone else up on the VPN, you could probably get that to work (you'd need to mess with DNS, AllowedIPs, and iptables rules to only allow port 443 access for your family's clients). I might look into that.

It's a security trade off, if an arbitrary person can't access your Nextcloud instance, neither can an attacker.

Sure (and I agree), but that means it's not a feature. But after reading your earlier comment, I have set nginx to only permit NextCloud traffic if I'm on the local network (I can't block everything because my personal website and Matrix homeserver need to be publicly accessible in order to function, and there's no way in hell I'm hosting my homeserver anywhere other than at home).

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

#134

Post by emptysands »

jacquesm wrote: post #82
zubspace wrote: post #76

Earlier quoted context omitted.

According to [1] mailinabox seems to be not affected. [1] https://github.com/mail-in-a-box/mailinabox/issues/1663#issu...

Good news, and good to see them respond so fast as well. I looked through the config files (could not get the exploit to work for some reason) and found the exact offending lines and jumped to the wrong conclusion. Weird how the config appears to have the exact setup that NextCloud has and yet it does not seem to be exploitable. Wonder why that is.

Exploit required specific combination of software and config lines. MIAB didn't have those lines.

That's not to say another similar exploit might have worked a different way. Luckily that bug is patched now.

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

#135

Post by antocv »

teddyh wrote: post #121
antocv wrote: post #112

Earlier quoted context omitted.

Lets Encrypt does not per se, but TLS does is what I mean with letsencrypt, thats why I said dont put a domain name for your nextcloud instance - because even if you get a wildcard cert, the domain names are public, and every lookup you do of your subdomain is visible to all ISPs, so even if you call it zyrkon.yourdomain.com someone can still attempt to make requests to it like /index.php?a Put your services, on a sh…

> thisISAlmostLikeaPassword Why not just add real HTTP authentication to the site instead? One should always be wary of password-like mechanisms like secret paths, secret ports, etc. since none of these things are made to be secret, and could be disclosed by something unforeseen. (Paths, for instance, are saved in your browser history/cache, your HTTP caching proxy, if any, and also in the server’s access logs.)

Of course the site has its normal login/password, for example nextcloud has authentication.

But you see, for what we are discussing here, you could have exploited it even without authenticating, and especially it would have been easier for scanners to find it and exploit, if it was on its own domain.

Defense in depth.

For some services, yes I do basic http auth, besides their own shitty auth.

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

#136

Post by antocv »

heavyset_go wrote: post #126
antocv wrote: post #112

Earlier quoted context omitted.

Lets Encrypt does not per se, but TLS does is what I mean with letsencrypt, thats why I said dont put a domain name for your nextcloud instance - because even if you get a wildcard cert, the domain names are public, and every lookup you do of your subdomain is visible to all ISPs, so even if you call it zyrkon.yourdomain.com someone can still attempt to make requests to it like /index.php?a Put your services, on a sh…

If you're worried about your ISP or people snooping on your traffic, then this scheme can be trivially defeated with a downgrade attack or looking at your address bar.

My ISP can not "be looking at your address bar", you are thinking of Google.

Downgrade attack, would not work since I use HTTPS Everywhere, and once my browser has visited the site it refused to downgrade - that header is set.

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

#138

Post by jeremija »

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

Thanks for the link! The example in the link does not contain the

   set $path_info $fastcgi_path_info;
line after the `fastcgi_split_path_info` directive.

My old configuration used the `$fastcgi_path_info`, and the new one uses the `$path_info` variable, so I got the following error while starting nginx:

    nginx emerg unknown "path_info" variable
Might be worth checking out the sample from the Nextcloud Admin Manual[1]

[1]: https://docs.nextcloud.com/server/17/admin_manual/installati...

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

#139

Post by maxymajzr »

NightlyDev wrote: post #60
maxymajzr wrote: post #43

Earlier quoted context omitted.

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 i…

> Mod_php was always faster at executing scripts

I've never, ever witnessed that mod_php came close to be fast, let alone faster than PHP-FPM. There's more work to be done in order to prepare everything needed for Apache to pass the data to PHP executable once it embeds it within its own process. Once opcache is up and running, PHP-FPM blows mod_php away (and there are tools to warm up the cache prior to letting the php-fpm node go live).

> 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

I've been present when the "hype" as you called it hit. It had nothing to do with memory as much as it did with scaling. Added benefit was the ability to have PHP-FPM act as a multiplexer towards certain services (database to name one).

Today, there's no reason to use Apache and mod_php. It's slower and worse by definition. It can't be faster. If you receive results that show it is faster, you're either testing it wrong or your PHP-FPM runs on a raspberry pi.

Post reply on HN