Nasty PHP7 Remote Code Execution Bug Exploited in the Wild on NGINX Servers

nickwinlund77 shares this story from ZDNet: A recently patched security flaw in modern versions of the PHP programming language is being exploited in the wild to take over servers, ZDNet has learned from threat intelligence firm Bad Packets. The vulnerability is a remote code execution (RCE) in PHP 7, the newer branch of PHP, the most common programming language used to build websites.

The issue, tracked as CVE-2019-11043, lets attackers run commands on servers just by accessing a specially-crafted URL. Exploiting the bug is trivial, and public proof-of-concept exploit code has been published on GitHub earlier this week. Only NGINX servers with PHP-FPM enabled are vulnerable. PHP-FPM, or FastCGI Process Manager, is an alternative PHP FastCGI implementation with some additional features, and according to reports, a common server configuration option.

Fixed on versions...

[QuietLagoon]

According to the zdnet.com article:

One such case is web hosting provider Nextcloud, who issued a security advisory to its clients on Thursday, October 24, urging customers to update PHP to the latest release, versions 7.3.11 and 7.2.24, which had been released on the same day and included fixes for CVE-2019-11043.

Re:

[johnsie]

That's ok, anyone who is good at programming stopped using PHP a long time ago due to all the insecure php libraries. Unfortunately a lot of of those developers failed to update their projects before jumping ship.So maybe they are not good at programming after all.

Repeat on Monday

[The New Guy 2.0]

Uhm, the NFL is on right now... is that why this Must-fix-business-software story not getting a reaction here?

Re:

[godrik]

Alternatively, slashdot is not as relevant as it used to be.
The site was even unreachable for hours yesterday.
I wonder how long it will take until netcraft confirms slashdot demise.

Re:

[Anrego]

This. There just isn't much to say about it. PHP exploit announced, fix released, people who care are mitigating, people who don't.. don't.
Even the people who enjoy trashing PHP for its spotty security record have gotten bored of it.

Re: Repeat on Monday

[bill_mcgonigle]

You need to be using nginx, php_fpm, and have a config using fastcgi_split_path_info, at least for today.

The recommend workaround is to find every instance of:
location ~ \.php(/|$) {
where fastcgi_split_path_info is used and prepend the location directive with:
rewrite ^(.*?)\n $1; #Fix CVE-2019-11043 (THIS LINE!!!)
to take newline characters out of URI's and get back to football until patches arrive.

no preview on mobile ... hope that's legible...

Re:

[gaspyy]

There's already a patch, released on Oct. 24.

Re:

[johnsie]

You're assuming that PHP developers and/or the mugs who they sell their software too are actually smart enough to patch their systems. If they are really that smart, why would they be using php?

Re:

[cordovaCon83]

*slow claps* Beautiful use of "begging the question" logical fallacy. This doesn't mean I disagree with you in general - I think using PHP is probably a bad idea in general. However, my employer does not, and I do not have the say-so to argue with him about it. I do, however, have the duty of making sure my employer's systems are as tight as I can make them. Ergo, I suppose I am smart enough to patch our PHP systems but not smart enough to explain to my boss why PHP was a terrible idea in the first place? H

Yikes

[TFlan91]

I think this is even more concerning:

The buffer underflow in php-fpm is present in PHP version 5. However, this exploit makes use of an optimization used for storing FastCGI variables, _fcgi_data_seg. This optimization is present only in php 7, so this particular exploit works only for php 7. There might be another exploitation technique that works in php 5.

Bug exists in PHP 5, but no one has found a way to utilize it yet.

PHP 5 is going to live on the web for as long as the web lives...

Re:

[93 Escort Wagon]

PHP 5 is going to live on the web for as long as the web lives...

Certainly for as long as RHEL/CentOS 7 lives, at a minimum...

Re:

[Billly Gates]

And you can thank SystemD for forcing server admins in using CentOS6/RH 6 with php 5 since systems can't be reliable with anything newer

Re: Yikes

[antus]

Any EL6/EL7 admin needing php should be using suported versions in the remi repos. Also redhat should backport a fix, even to versions unsupported in upstream, because thats what the do. Stable APIs, security patches for the life of the OS.

Re: Yikes

[aSplash0fDerp]

I haven't touched NGINX and php-fpm since 2013, but I still can't say enough nice things about that combo. It was rocket fuel!

Yeah, I can see how PHP 5 is going to stick around for as long as it can. I don't miss the update drama/lottery with any of those components one bit. It was almost like most code was destined to break at some point after an update.

Alternative fix for use with stable versions

[itsgameoverman]

According to the bug report:

The regexp in `fastcgi_split_path_info` directive can be broken using the newline character (in encoded form, %0a). Broken regexp leads to empty PATH_INFO, which triggers the bug.

According to NGINX documentation:

If the directive is specified with if_not_empty (1.1.11) then such a parameter will be passed to the server only if its value is not empty:

So this line in your configuration should prevent the problem in older versions of NGINX:

fastcgi_param PATH_INFO $fastcgi_path_in