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

111–120 of 139 posts

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

#111

Post by Lorkki »

swiley wrote: post #68
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...

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

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

#112

Post by antocv »

organsnyder wrote: post #56
antocv wrote: 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).

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 shared domain name, only yourdomain.com and under a sub-path, like yourdomain.com/thisISAlmostLikeaPassword/nextcloud the subpath is hidden by TLS, unless you make it public by posting it on the internet. And also if you arent careful, like using google "auto-suggest" or just using any Google products, then they will at least know about your path.

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

#113

Post by antocv »

labawi wrote: post #77
Xylakant wrote: post #69

Earlier quoted context omitted.

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

I haven't studied the issue, but it requires to access/execute php, no? If configuration requires a path to get further than a canned reply from nginx (403, 404, static page..), then it should reduce attack surface a lot. You should not be able to get anywhere near php without the path.

Exactly.

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

#114

Post by ossworkerrights »

cnst wrote: post #97
throwawayRO1999 wrote: post #29

Earlier quoted context omitted.

In Romanian as well

How? Romanian is not a Slavic language, I thought both of these are Slavic-rooted words.

The Romanian language has loads of slavic words. Nevesta, ultia, curva, and so on, thanks to its proximity to slavic countries.

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

#115

Post by s_gourichon »

noja wrote: post #47
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's not.

"Argument is an intellectual process. Contradiction is just the automatic gainsaying of anything the other person says."

http://www.montypython.net/scripts/argument.php

https://www.youtube.com/watch?v=ohDB5gbtaEQ&t=74

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

#116

Post by elyobo »

im3w1l wrote: post #90
antocv wrote: post #40

Earlier quoted context omitted.

If anyone is following standard "recommended" practice, like in Nextcloud case, they get burned. This is true for all languages and frameworks. If you dont practice defense-in-depth, you get rekt eventually. I just checked my installation, its safe, since I didnt follow their "recommended" settings at all. Since its a PHP app, what I do is put an extra nginx proxy infront of it, so there is nginx 1 (this one runs in…

The recommended way off installing it uses apache instead of nginx, which happens not to be vulnerable. Only if you looked up their instructions for nginx did you get burned.

I didn't realise that the recommendation had gone back the other way again; any good resources discussing current recommendations and the whys?

We have a fair bit of legacy stuff hanging around, all nginx+php, none of which appear to be vulnerable due to consistent use of try_files.

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

#117

Post by im3w1l »

elyobo wrote: post #116
im3w1l wrote: post #90

Earlier quoted context omitted.

The recommended way off installing it uses apache instead of nginx, which happens not to be vulnerable. Only if you looked up their instructions for nginx did you get burned.

I didn't realise that the recommendation had gone back the other way again; any good resources discussing current recommendations and the whys? We have a fair bit of legacy stuff hanging around, all nginx+php, none of which appear to be vulnerable due to consistent use of try_files.

I have no idea why. I just based it on https://docs.nextcloud.com/server/17/admin_manual/installati...

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

#118

Post by elyobo »

im3w1l wrote: post #117
elyobo wrote: post #116

Earlier quoted context omitted.

I didn't realise that the recommendation had gone back the other way again; any good resources discussing current recommendations and the whys? We have a fair bit of legacy stuff hanging around, all nginx+php, none of which appear to be vulnerable due to consistent use of try_files.

I have no idea why. I just based it on https://docs.nextcloud.com/server/17/admin_manual/installati...

Ah, I misunderstood your comment sorry - I thought you meant recommendations for installing _PHP_ + some web server in general, not nextcloud specifically!

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

#119

Post by meowface »

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…

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

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

#120

Post by VvR-Ox »

gallexme wrote: post #6
thesorrow wrote: post #5

I'm sure a lot of PHP 7.0 installations are still in production and will not receive a patch...

Yup, we run like 50 sites on php 5.3 atm and just 5 with 7+ php industry is weird and update shy in my experience... Atleast in Europe

OMG! Don't you ever have problems with those sites? Not just security but speed is also something I'd consider.

It's time to upgrade if you want to stay secure: https://www.php.net/supported-versions.php

Post reply on HN