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

101–110 of 139 posts

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

#101

Post by cyphar »

nominated1 wrote: post #55
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.

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…

How do you port-scan for WireGuard? The handshake design is designed to not respond to packets in the opening handshake unless the peer already knows your public key.

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

#102

Post by nominated1 »

cyphar wrote: post #101
nominated1 wrote: post #55

Earlier quoted context omitted.

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…

How do you port-scan for WireGuard? The handshake design is designed to not respond to packets in the opening handshake unless the peer already knows your public key.

Right, portscanning won’t work on Wireguard. Port knocking can provide an additional layer of protection against an unknown vulnerability, even for Wireguard. Sorry for the confusion.

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

#104

Post by cyphar »

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?

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 whitelist only sharing-links for instance), but now you've hit usability problems again.

I mitigate code execution worries by running all of my services in individual LXD containers. They're all using isolated user namespaces (unique mappings), and are firewalled away from being able to access my internal network. The data is bind-mounted from a ZFS filesystem which is backed up by the host and uploaded to BackBlaze. The containers themselves are also snapshotted by ZFS. Thus, I think the risks of exploits being able to do much damage are greatly reduced.

However, there is still a worry about information disclosure. Yeah, NextCloud can only access the documents it manages -- but some of those documents are somewhat sensitive. I don't know what the ideal solution for this would be (a wholly separate NextCloud instance just for accessing the private stuff? But what if your family needs to access them?). My main worry when hosting NextCloud was that I am entirely trusting the safety of my NextCloud-stored data to an authentication flow that they wrote themselves in PHP (and has had pretty ugly flaws such as silently disabling 2FA or letting you bypass it by clicking "cancel".)

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

#105

Post by Dylan16807 »

wolco wrote: post #18
kijin wrote: post #2

Ubuntu has a try_files directive in /etc/nginx/snippets/fastcgi-php.conf that is included by default. It was put there years ago to guard against another problem (also mentioned by OP), but it seems that the try_files directive will block this one, too. Unfortunately, too many people still copy & paste three-liners from random blogs and call it a day, often overwriting the safe defaults provided by their distro, er,…

CentOS isn't marketed as a desktop distro. The listening default is helpful and when I switched over to Ubuntu that default of not listening confused me. Not sure I see the benefit.. it's like installing windows but the internet is disabled by default and must be configured manually.. installing another browser and you must configure it manually.

Listening on localhost, or a socket, is a reasonable default. Listening to nothing is annoying, and listening to everything is a terrible idea.

If you're spreading one service across multiple servers, you can spare the few seconds to open up IPs/ports. The default should keep things moderately secure on a single host.

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

#106

Post by arpa »

meowface wrote: post #89
root_axis wrote: post #73

Earlier quoted context omitted.

Well sure, if restoring from backups means you will be working unpaid overtime then it'd be worth working less overtime to stave off more, but in practice restoring from backups is a time-consuming process for computers, not for people. Realistically though, enjoying your Sunday and digging into work issues on Monday is probably not going to be a big deal.

There's also the small issue that every minute that passes is another potential minute an attacker is stealing sensitive data, PII, and email/IM logs from your company's internal network, and backdooring other servers, installing ransomware, etc. That requires far more than a wipe and restore to deal with, and could potentially result in a massive financial and reputational loss.

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 these exploits just right. The possibility is not that high if you're not a high profile target and if you're a high profile target, well, you should know better than to keep all of your eggs in the same basket. And if it's a shared vps where such things can actually happen, the hosting provider should take care if it.

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

#107

Post by tetha »

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.

In this case we're talking about 5 VMs running php-fpm and no nginx in sight, so these VMs aren't immediately affected by said exploit. Also, these VMs only consume some public, unauthenticated APIs of the company and render the concent into some pretty HTML. These boxes have no persistence, no access to PII and no access to anything you can't get with curl right now.

Worst-Case, they can try sending some spam mails or DDoS-attacks, in which case the hoster would zero-route/force-stop them as soon as that's detected. And then I'd have to rebuild them with ~30 minutes waiting for teraform.

So yes, I'm going to act accordingly. By not bothering on a sunday, because the systems are properly isolated and there are procedures in place.

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

#108

Post by dvfjsdhgfv »

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.

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.

Second, bugs are found every day, and your best bet is to use automatic security updates provided by your distro. Yes, if you host anything, you need to be a bit of a security guy and a small amount of paranoia won't hurt. But to say you must not self-host for security reasons is a gross oversimplification.

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

#109

Post by mantoto »

arpa wrote: post #106
meowface wrote: post #89

Earlier quoted context omitted.

There's also the small issue that every minute that passes is another potential minute an attacker is stealing sensitive data, PII, and email/IM logs from your company's internal network, and backdooring other servers, installing ransomware, etc. That requires far more than a wipe and restore to deal with, and could potentially result in a massive financial and reputational loss.

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…

And who has seen proper Microservicearchitektur? I haven't. Only now how it should look like.

Soo you use microservices? Yes! Sooo why can I not find more then one database?

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

#110

Post by tialaramex »

mfontani wrote: post #79
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'm currently serving some of my "internal" services (a wiki, a coffee tracker; things like that - nothing fancy) only from a zerotier network my devices can connect to. Thanks to letsencrypt "now" (for some time, I know.. but I wanted to do this way before they allowed one to) allowing wildcard TLS certs, I host the above on a domain which doesn't have a single public IP DNS entry, yet has full proper "validated, br…

Note that in any configuration where you end up asking remote DNS servers about some particular name the operator might well be selling the list of names queried and their answers, this is called "passive DNS" and is aggregated then sold on so it isn't PII by the time it's sold (purchasers can't tell who asked, only what was asked and what the answer was)

Where people set wildcard DNS this means passive DNS reveals typos, as well as such "hidden" services. wwww.example.com and ddd.example.com are common typos for www for example whereas int-test.example.com is maybe interesting to black hats.

Post reply on HN