Interesting to see the exploit written in Go. Proof, maybe, that Go has finally landed.
PHP-FPM remote code execution bug exploited in the wild
91–100 of 139 posts
Re: PHP-FPM remote code execution bug exploited in the wild
#92Earlier quoted context omitted.
Common approach is to serve static files with nginx and use apache / php_mod to process. Why are you running php-fpm? Do you need to separate request's processes? The speed benefits of php-fpm are part of php 7 so using php_mod is faster now.
> Common approach is to serve static files with nginx and use apache / php_mod to process. Not sure how common that really is, I've personally never set things up like that and just use nginx + php-fpm and don't know anyone that still uses apache with mod_php.
I think its the default on Plesk installs
Re: PHP-FPM remote code execution bug exploited in the wild
#93For those of you not speaking Russian, Russian for ‘dick’ & ‘cunt’ (also meaning ‘something very bad happening’) are in the title.
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").
Re: PHP-FPM remote code execution bug exploited in the wild
#94Does anyone know if this exploit has any lasting effects? After this, you can start appending ?a= to all PHP scripts (you may need multiple retries). I'd love some way to confirm that my mitigations have worked and that I am no longer vulnerable but, y'know, running random slavic exploits against the server seems a bit sketchy.
Didn’t look at the code that closely, but there’s an option to only test the server for the exploit. As long as that is enabled, it doesn’t appear to write any files, etc.
I would say it might be better to just test against a localhost server in a VM to be on the safe side though.
Re: PHP-FPM remote code execution bug exploited in the wild
#95Earlier 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.
The stream of new security threats is never-ending, thus security must be a process that incorporates the reality that employees sometimes have days when they aren't working. Clearly, the OP is not being paid for 24/7 on-call security consulting, so why should they sacrifice their day off to investigate and patch security vulnerabilities?
Re: PHP-FPM remote code execution bug exploited in the wild
#96Earlier quoted context omitted.
App security is still not on a par with other language ecosystems.. I don't think for example I've heard of a Python based SQL injection in many years. Stuff like that seems to still crop up regularly in PHP land
Now you are confusing security of PHP as a platform with security of applications written in PHP. Python had 2 RCEs in 2018: https://www.cvedetails.com/vulnerability-list/vendor_id-1021... None in 2019 so far. PHP has none in 2018 and has one in 2019 so far (there's another one in http module but it's not part of the core). > I don't think for example I've heard of a Python based SQL injection in many years. Stuff li…
> Now you are confusing security of PHP as a platform with security of applications
The parent comment explicitly made this distinction
Re: PHP-FPM remote code execution bug exploited in the wild
#97Re: PHP-FPM remote code execution bug exploited in the wild
#98Earlier quoted context omitted.
Common approach is to serve static files with nginx and use apache / php_mod to process. Why are you running php-fpm? Do you need to separate request's processes? The speed benefits of php-fpm are part of php 7 so using php_mod is faster now.
> Common approach is to serve static files with nginx and use apache / php_mod to process. Not sure how common that really is, I've personally never set things up like that and just use nginx + php-fpm and don't know anyone that still uses apache with mod_php.
Plenty of stuff still uses it, unfortunately. Performance is pretty janky, I just moved a Mediawiki install from Apache+mod_php to Nginx+php-fpm as part of getting the site(s) on kubernetes and it’s tremendously better to work with and uses less memory due to not needing mpm_prefork.
Re: PHP-FPM remote code execution bug exploited in the wild
#99> 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.
Well, for what it's worth, I think the best practice was always to test the existence of the PHP script, either with `try_files`, or with `if`, so, if you do that, then you aren't vulnerable, according to the exploit.
E.g., if you follow the "PHP FastCGI Example" from nginx.com, then nginx would protect you from this vulnerability in PHP-FPM:
* http://web.archive.org/web/20150928021324/https://www.nginx....
Here's the current version of the page, which seems to have the same info as the archived one above:
* https://www.nginx.com/resources/wiki/start/topics/examples/p...
(I think it used to be at another URL prior to the involvement of the marketing department in 2015; not sure if it's worth finding at this point, because the bug is not even in nginx in the first place.)
Re: PHP-FPM remote code execution bug exploited in the wild
#100Interesting to see the exploit written in Go. Proof, maybe, that Go has finally landed.
I noticed that, too. Including a `go get` instruction to get it, no less.