14 ms·
PHP-FPM remote code execution bug exploited in the wild
- kijin 7y agoUbuntu 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, I mean, Debian/Ubuntu. (edit: The RPM world is a whole different beast. When you install typical LEMP components on CentOS 7, both MySQL and Memcached listen on all interfaces by default. Seriously?!)
- wolco 7y agoCentOS 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.
- Dylan16807 7y agoListening 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.
- lioeters 7y agoI confirmed that Ubuntu's default config in /etc/nginx/snippets/fastcgi-php.conf has a try_files directive that prevents this exploit.
- hnarn 7y agoFrom the CVE: > Solution > On October 24, PHP 7.3.11 (current stable) and PHP 7.2.24 (old stable) were released to address this vulnerability along with other scheduled bug fixes. Those using nginx with PHP-FPM are encouraged to upgrade to a patched version as soon as possible. > If patching is not feasible, the suggested workaround is to include checks to verify whether or not a file exists. This is achieved either by including the try_files directive or using an if statement, such as if (-f $uri).
- calibas 7y agoShould probably have specified in the title that it's a PHP-FPM bug, had me worried there.
- dang 7y agoOk, we've added that to the title.
- thesorrow 7y agoI'm sure a lot of PHP 7.0 installations are still in production and will not receive a patch...
- gallexme 7y agoYup, 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
- VvR-Ox 7y agoOMG! 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 https://www.php.net/supported-versions.php
- kijin 7y agoThey will receive a patch if they're using it on a Linux distro that is still supported (e.g. Ubuntu 16.04 LTS). How many people actually bother to run apt-get update && apt-get upgrade on their cloud servers or docker images is a different question, though.
- oefrha 7y agoProbably a good idea to auto install security updates. At least that’s what I do on my servers.
- thinkingemote 7y agoI think it's the default for several years now but I imagine it's not normal for a security update in PHP to restart an nginx process? Maybe it is.
- kgersen75 7y agoThe issue is PHP-FPM (FastCGI) only and it's vulnerable from outside only with nginx. The vast majority of PHP 7.0 installations don't use FastGCI and don't use nginx but Apache simply because people used 'apt install php' (or 'yum install php') to install it. So imho, the impact is very limited.
- jstanley 7y agoThe exploit requires > fastcgi_split_path_info ^(.+?\.php)(/.*)$; If I'm not using this feature of PHP, what can I put in this config value to prevent the exploit from working?
- tyingq 7y agoI don't think you can fix it there, because you probably need stuff like /foo.php?key=value to work. (Edit: not quite...see comment below) The try_files config mentioned on the page mitigates the issue.
- makomk 7y agoI don't think this line is required to make foo.php?key=value to work, because the query parameters aren't treated as part of the path. It's for URLs like foo.php/bar where you have some path after the PHP file that's passed to the script - this was supported out the box by Apache mod_php and there's a fair amount of code out there that relies on it. (Generally because cleaner methods of feeding a set of paths to one PHP script require server configuration that may not be available on cheap shared web hosting.)
- tomclancy 7y ago>There must be a PATH_INFO variable assignment via statement fastcgi_param PATH_INFO $fastcgi_path_info;. At first, we thought it is always present in the fastcgi_params file, but it's not true. This is also precondition, and fortunately it's not included in standard fastcgi_params files.
- mike-cardwell 7y agoThis affects the default documented Nextcloud config. They blogged about it the other day: https://nextcloud.com/blog/urgent-security-issue-in-nginx-php-fpm/ https://nextcloud.com/blog/urgent-security-issue-in-nginx-ph...
- thesorrow 7y agoFYI : 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-php-fpm/ https://nextcloud.com/blog/urgent-security-issue-in-nginx-ph...
- ralala 7y agoThe production-fpm docker image has not yet received any updates - correct?
- heavyset_go 7y agoThis is a case study in why you shouldn't expose your self-hosted services to the internet.
- kuzimoto 7y agoI have been thinking about this a lot lately. What is the best alternative, only accessing your services through a VPN?
- PureParadigm 7y agoI've transitioned all my self-hosted services to behind a Wireguard VPN. This even includes SSH, so there are no ports exposed except the UDP port for Wireguard.
- heavyset_go 7y agoVPN or SSH tunnels. I just use WireGuard these days.
- antocv 7y agoI 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.
- 7y ago
- orf 7y agoThe commit that fixes it: https://github.com/php/php-src/commit/ab061f95ca966731b1c84cf5b7b20155c0a1c06a https://github.com/php/php-src/commit/ab061f95ca966731b1c84c...
- samat 7y agoFor those of you not speaking Russian, Russian for ‘dick’ & ‘cunt’ (also meaning ‘something very bad happening’) are in the title.
- throwawayRO1999 7y agoIn Romanian as well
- cnst 7y agoHow? Romanian is not a Slavic language, I thought both of these are Slavic-rooted words.
- ossworkerrights 7y agoThe Romanian language has loads of slavic words. Nevesta, ultia, curva, and so on, thanks to its proximity to slavic countries.
- fortran77 7y agoI'd say it's in Croatian. In Russian, it's "пизда"
- owl57 7y agoNo, that's certainly just transliterated Russian: https://github.com/neex/phuip-fpizdam/blob/d43b788a65f83ba6fd3f95bf0710432c01f434b7/requester.go#L75 https://github.com/neex/phuip-fpizdam/blob/d43b788a65f83ba6f... (those literals mean "Fucking: your mom").
- fortran77 7y agoYes! My Grandmother grew up in Belarus, but she knew some Russian words--mostly curses--and taught them to me!
- arpa 7y agoLuckily, php 7.1 has still left a month for security fixes. This is patched in 7.1.33.
- geoffmcc 7y ago> 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.
- jacquesm 7y agoMailinabox as well.
- zubspace 7y agoAccording to [1] mailinabox seems to be not affected. [1] https://github.com/mail-in-a-box/mailinabox/issues/1663#issuecomment-546448061 https://github.com/mail-in-a-box/mailinabox/issues/1663#issu...
- jacquesm 7y agoGood news, and good to see them respond so fast as well. I looked through the config files (could not get the exploit to work for some reason) and found the exact offending lines and jumped to the wrong conclusion. Weird how the config appears to have the exact setup that NextCloud has and yet it does not seem to be exploitable. Wonder why that is.
- emptysands 7y agoExploit required specific combination of software and config lines. MIAB didn't have those lines. That's not to say another similar exploit might have worked a different way. Luckily that bug is patched now.
- cnst 7y agoWell, 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.com/resources/wiki/start/topics/examples/phpfcgi/ 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/phpfcgi/ 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.)
- gsmith2 7y agoAs good a time as any to be reminded.. if you have to run any kind of PHP app, always keep it in its own VM and preferably with no access to anything except its own databases, and ideally with minimal outbound Internet access. PHP security has improved markedly over time (especially app security, not just the runtime), but it's still.. well.. stuff like this. This time around I'm lucky that the sole app I run was using Apache
- smsm42 7y agoYou sound like PHP is somehow particularly bad in this regard. While this issue is nothing to be proud of, same kind of issues (and other RCE-causing issues too) are regularly found in many major products and libraries. There's no reason to specifically shame PHP for something that happens everywhere. Good defense is depth practices are always good idea, but no need to motivate it by casting PHP as some kind of particularly villainous.
- gsmith2 7y agoApp 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
- smsm42 7y agoNow 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-10210/product_id-18230/year-2018/opec-1/Python-Python.html 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 like that seems to still crop up regularly in PHP land This is an extremely subjective statement based on your personal experience of what you heard and didn't. As such, it's not verifiable and not useful. What is useful is to know that, obviously, PHP, as well as Python, has SQL implementations that eliminate injections for decades. And as in Python, there could be people that ignore it and stuff query params directly into strings. This has nothing to do with anything but these people being ignorant. There are of course tons of web apps in PHP, much more than in Python, so among them inevitably would be crappy ones. If you run one of them, do take precautionary measures.
- denton-scratch 7y agoMy job used to include writing PHP webpages that were exposed to the internet, and looking after the webservers they were running on. I'm, not responsible for any public-facing webservers any more. My life is much better. [Edit: I reckon using a well-designed functional language might reduce the risk - like, PHP was never designed at all, it grew by accretion]
- antocv 7y agoIf 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 its own lxc container with seccomp and has not even a /bin/sh in it, only executables and libc required for nginx, its only a network reverse proxy) - nginx2 (special instance for each php app, also same as nginx1 container with _nothing_ in it, but also a bind mounted ipc_socket which is also mounted to php_app container. So the php_app container and nginx2 share only 1 ipc.socket bind mounted from the host. Now then, in the php app container, there is also lack of /bin/sh or anything else, not even the package manager, only what php-fpm requires, and the nextcloud .php scripts, are in there. _nothing_ else. So even if this exploit would have worked, there would still be nothing standard to run in the php-app container (like /bin/ls), except the php scripts themselves, though thats bad enought to steal my nextcloud data.
- im3w1l 7y agoThe 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.
- elyobo 7y agoI 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.
- fortran77 7y agoWow! I'm glad I saw this today. The server we use to host our corporate blog was vulnerable. I updated the php-fpm to the latest and I think I'm OK now.
- zubspace 7y agoCan someone confirm, that it will still take 6 days until fedora servers get patched, except if i get it from testing? [1] Is this the norm for CVE's ? How long does it take other distros to patch? Also: Am I secure if i run PHP 7.2.24 or do I need to change the configs? [1] https://bodhi.fedoraproject.org/updates/FEDORA-2019-187ae3128d https://bodhi.fedoraproject.org/updates/FEDORA-2019-187ae312...
- tetha 7y agoHmm, 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 utilizing php-fpm in this version remains vulnerable, and it's just unknown if or how apache + php-fpm, or other reverse proxies for php-fpm are vulnerable - right? So while I don't need to panic right now, I'll certainly have to take a look at our setups running php-fpm on monday.
- mantoto 7y agoOn Monday? Assume your systems are compromised and act accordingly.
- root_axis 7y agoSome people choose not to work on weekends. Work/life balance etc.
- PeterisP 7y agoSure, but the price of not having 24/7 support may be that instead of applying a patch you get to nuke everything from orbit and rebuild from backups.
- root_axis 7y agoSure, 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.
- PeterisP 7y agoIt 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 next week.
- nucleardog 7y agoDoes anyone know if this exploit has any lasting effects? After this, you can start appending ?a=<your command> 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.
- x3sphere 7y agoDidn’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.
- good_guy 7y agoIf you are managing a php server and asking this question then you have bigger problems.
- Kiro 7y agoI 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).
- nullify88 7y agoI 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.
- EGreg 7y agoFunny that php5 is safe from it
- smsm42 7y agoActually not, it's safe from the exploit published, but not from the actual bug.
- cutler 7y agoInteresting to see the exploit written in Go. Proof, maybe, that Go has finally landed.
- cnst 7y agoI noticed that, too. Including a `go get` instruction to get it, no less.
- deleted 7y ago[deleted]