> If a webserver runs nginx + php-fpm and nginx have a configuration like And it's the config settings every blog ive ever seen about nginx + php-fpm said to use. So I think a lot of sites are vulnerable right now.
Mailinabox as well.
PHP-FPM remote code execution bug exploited in the wild
71–80 of 139 posts
Re: PHP-FPM remote code execution bug exploited in the wild
#72FYI : 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...
Or something that includes NextCloud or Owncloud even if you do not use them, such as Mailinabox.
Re: PHP-FPM remote code execution bug exploited in the wild
#73Earlier quoted context omitted.
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…
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.
Re: PHP-FPM remote code execution bug exploited in the wild
#74I 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).
I would suggest having a try_files in the .php location. Because it just takes someone sending a request to index.php for Nginx to process the request in a potentially vulnerable location block that doesn't have try_files.
You perhaps might not be vulnerable if you use an internal directive inside your .php location block.
Re: PHP-FPM remote code execution bug exploited in the wild
#75Funny that php5 is safe from it
Re: PHP-FPM remote code execution bug exploited in the wild
#76> If a webserver runs nginx + php-fpm and nginx have a configuration like And it's the config settings every blog ive ever seen about nginx + php-fpm said to use. So I think a lot of sites are vulnerable right now.
Mailinabox as well.
According to [1] mailinabox seems to be not affected.
[1] https://github.com/mail-in-a-box/mailinabox/issues/1663#issu...
Re: PHP-FPM remote code execution bug exploited in the wild
#77Earlier 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).
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.
Re: PHP-FPM remote code execution bug exploited in the wild
#78FYI : 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.
Do you just want WebDAV and nothing else? There’s plenty of Docker images for that and most of them are just Apache with the relevant plugin and config.
Re: PHP-FPM remote code execution bug exploited in the wild
#79Earlier 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?
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, browser approved" TLS cert.
IOW, I fire up my zerotier client on my phone, open brave, put the URL in, and off I go. https, and for my eyes only.
It's great!
Re: PHP-FPM remote code execution bug exploited in the wild
#80Funny that php5 is safe from it
Actually not, it's safe from the exploit published, but not from the actual bug.