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

121–130 of 139 posts

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

#121

Post by teddyh »

antocv wrote: post #112
organsnyder wrote: post #56

Earlier quoted context omitted.

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

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

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

#122

Post by WorkLobster »

Lorkki wrote: post #111
swiley wrote: post #68

Earlier quoted context omitted.

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.

Seafile has been working for me as a personal Dropbox replacement, with s3ql for mass storage. It's very light in relation to Nextcloud/Owncloud (a primary criterion for me trying to cheap out on servers), supports WebDAV, role-based access and a bunch of SSO options. The biggest possible drawback I can think of is that it doesn't store files in the plain, so you can't trivially tie in SFTP or serve files from the st…

Re: files in the plain, the server application is bundled with a daemon that allows you to access files locally as a read-only FUSE mount, e.g.:

   seaf-fuse.sh start /mnt/seafile
I find it pretty handy when running a web server on the same host: drop files into a folder on my local machine, and they show up in the web root in seconds!

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

#123

Post by mtbcoder »

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. 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 depending on the number of threads.

It's not far superior as the "overhead" of CGI is negligible in the real world. Plus you can pool processes for better scaling. Also, if you are using prefork with mod_php (which is the most probable scenario) it means you are forking an entirely new Apache process and not just "loading PHP" with each request.

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

It's not hype, because for a long time, mod_php required prefork because it was not thread-safe (even now it's still a pain to manage re-compiling PHP to be thread-safe for mod_php + Apache)...which means you could not take advantage of mpm_event or mpm_worker.

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

#124

Post by fortran77 »

owl57 wrote: post #93
fortran77 wrote: post #39

Earlier quoted context omitted.

I'd say it's in Croatian. In Russian, it's "пизда"

No, that's certainly just transliterated Russian: https://github.com/neex/phuip-fpizdam/blob/d43b788a65f83ba6f... (those literals mean "Fucking: your mom").

Yes! My Grandmother grew up in Belarus, but she knew some Russian words--mostly curses--and taught them to me!

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

#125

Post by heavyset_go »

cyphar wrote: post #104
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?

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. I do use WireGuard for accessing services like SSH or NFS from the public internet, but the usability hit is a deal-breaker for my family. Client-side certificates would help solve this problem somewhat (you could whiteli…

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

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

#126

Post by heavyset_go »

antocv wrote: post #112
organsnyder wrote: post #56

Earlier quoted context omitted.

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

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.

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

#127

Post by heavyset_go »

dvfjsdhgfv wrote: post #108
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.

No, it was definitely not true in the past and is not true now. First, technically there is no much difference between a given app self-hosted by you and hosted by a company charging you for that except that in theory they should worry about these things instead of you. In practice, your experience will vary - companies happen to be as vulnerable as you, and for various reasons their reaction time might be longer. Se…

> But to say you must not self-host for security reasons is a gross oversimplification.

This is a gross oversimplification and straw man argument. You can self-host securely.

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

#128

Post by cyphar »

heavyset_go wrote: post #125
cyphar wrote: post #104

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. I do use WireGuard for accessing services like SSH or NFS from the public internet, but the usability hit is a deal-breaker for my family. Client-side certificates would help solve this problem somewhat (you could whiteli…

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

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

#129

Post by arpa »

meowface wrote: post #119
arpa wrote: post #106

Earlier quoted context omitted.

That seems far fetched in most saneish setups of PHP. The only risk, really, is the apps' own data. Which is also where microservices shine - chaining attacks like this is exponentially more difficult then. Unless, of course, your app is a monolith, isn't sandboxed and segregated from the rest of internal network (i.e. on the same server), and the rest of the network is very, very vulnerable so the attacker can chain…

I think you very greatly overestimate the typical level of isolation and "sanity" of most setups in general, let alone most PHP setups (which are likely generally much worse than most other setups).

Have more faith in fellow man, brother!

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

#130

Post by g8oz »

mtbcoder wrote: post #123
NightlyDev wrote: post #60

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. 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. 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.
Post reply on HN