
PHP-FPM remote code execution bug exploited in the wild - orangepanda
https://github.com/neex/phuip-fpizdam
======
thesorrow
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...](https://nextcloud.com/blog/urgent-security-issue-in-nginx-php-fpm/)

~~~
heavyset_go
This is a case study in why you shouldn't expose your self-hosted services to
the internet.

~~~
kuzimoto
I have been thinking about this a lot lately. What is the best alternative,
only accessing your services through a VPN?

~~~
cyphar
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".)

~~~
heavyset_go
> 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.

This is a feature. Besides, you can send friends and family a QR code to
connect to your WireGuard VPN. It isn't perfect, but it beats having your
personal data stolen.

~~~
cyphar
I don't see how "you cannot use the link sharing feature of NextCloud" is a
feature? Seems to be the precise opposite. As for setting everyone else up on
the VPN, you could probably get that to work (you'd need to mess with DNS,
AllowedIPs, and iptables rules to only allow port 443 access for your family's
clients). I might look into that.

~~~
heavyset_go
It's a security trade off, if an arbitrary person can't access your Nextcloud
instance, neither can an attacker.

~~~
cyphar
Sure (and I agree), but that means it's not a feature. But after reading your
earlier comment, I have set nginx to only permit NextCloud traffic if I'm on
the local network (I can't block everything because my personal website and
Matrix homeserver need to be publicly accessible in order to function, and
there's no way in hell I'm hosting my homeserver anywhere other than at home).

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

------
orf
The commit that fixes it: [https://github.com/php/php-
src/commit/ab061f95ca966731b1c84c...](https://github.com/php/php-
src/commit/ab061f95ca966731b1c84cf5b7b20155c0a1c06a)

------
tetha
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 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
On Monday?

Assume your systems are compromised and act accordingly.

~~~
root_axis
Some people choose not to work on weekends. Work/life balance etc.

~~~
PeterisP
Sure, 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
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.

~~~
PeterisP
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 next week.

~~~
root_axis
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.

~~~
meowface
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.

~~~
arpa
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.

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

~~~
arpa
Have more faith in fellow man, brother!

------
kijin
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, 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
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.

~~~
Dylan16807
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.

------
calibas
Should probably have specified in the title that it's a PHP-FPM bug, had me
worried there.

~~~
dang
Ok, we've added that to the title.

------
samat
For those of you not speaking Russian, Russian for ‘dick’ & ‘cunt’ (also
meaning ‘something very bad happening’) are in the title.

~~~
fortran77
I'd say it's in Croatian. In Russian, it's "пизда"

~~~
owl57
No, that's certainly just transliterated Russian:
[https://github.com/neex/phuip-
fpizdam/blob/d43b788a65f83ba6f...](https://github.com/neex/phuip-
fpizdam/blob/d43b788a65f83ba6fd3f95bf0710432c01f434b7/requester.go#L75) (those
literals mean "Fucking: your mom").

~~~
fortran77
Yes! My Grandmother grew up in Belarus, but she knew some Russian words--
mostly curses--and taught them to me!

------
geoffmcc
> 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
Mailinabox as well.

~~~
zubspace
According to [1] mailinabox seems to be not affected.

[1] [https://github.com/mail-in-a-
box/mailinabox/issues/1663#issu...](https://github.com/mail-in-a-
box/mailinabox/issues/1663#issuecomment-546448061)

~~~
jacquesm
Good 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
Exploit 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.

------
mike-cardwell
This affects the default documented Nextcloud config. They blogged about it
the other day: [https://nextcloud.com/blog/urgent-security-issue-in-nginx-
ph...](https://nextcloud.com/blog/urgent-security-issue-in-nginx-php-fpm/)

------
zubspace
Can 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-187ae312...](https://bodhi.fedoraproject.org/updates/FEDORA-2019-187ae3128d)

------
nucleardog
Does 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
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.

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

~~~
kijin
They 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
Probably a good idea to auto install security updates. At least that’s what I
do on my servers.

~~~
thinkingemote
I 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.

------
Kiro
I 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
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.

------
arpa
Luckily, php 7.1 has still left a month for security fixes.

This is patched in 7.1.33.

------
jstanley
The 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
I 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
I 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.)

------
gsmith2
As 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
You 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
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

~~~
smsm42
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...](https://www.cvedetails.com/vulnerability-
list/vendor_id-10210/product_id-18230/year-2018/opec-1/Python-Python.html)
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.

~~~
gsmith2
> Now you are confusing security of PHP as a platform with security of
> applications

The parent comment explicitly made this distinction

------
denton-scratch
My 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
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 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
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.

~~~
elyobo
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.

~~~
im3w1l
I have no idea why. I just based it on
[https://docs.nextcloud.com/server/17/admin_manual/installati...](https://docs.nextcloud.com/server/17/admin_manual/installation/source_installation.html)

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

------
fortran77
Wow! 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.

------
EGreg
Funny that php5 is safe from it

~~~
smsm42
Actually not, it's safe from the exploit published, but not from the actual
bug.

------
cutler
Interesting to see the exploit written in Go. Proof, maybe, that Go has
finally landed.

~~~
cnst
I noticed that, too. Including a `go get` instruction to get it, no less.

