CVE-2019-11043

KOM

https://nextcloud.com/blog/urgent-security-issue-in-nginx-php-fpm/

Dear system administrators,
In the last 24 hours, a new security risk has emerged around NGINX, documented in CVE-2019-11043.
This exploit allows for remote code execution on some NGINX and php-fpm configurations.
If you do not run NGINX, this exploit does not effect you.

Unfortunately the default Nextcloud NGINX configuration is also vulnerable to this attack.
We recommend all system administrators take immediate actions...

pfSense uses nginx and php-fpm. Is this of concern?

jimp

I can't find much info about that CVE yet. Some info on github and a POC, but no real analysis that I've run across. At a glance it does sound bad, if it is as stated, but usually it turns out that parts of it are a bit exaggerated.

Usually for the really bad things we get notified by CERT before the info is public for coordination, but nothing about this from them that I've seen either.

I haven't read through the POC code, so I'm not too eager to try it yet, but that's the best way to find out if it's a legitimate issue.

jimp

Updated the POC URL, looks like https://github.com/neex/phuip-fpizdam has better info, and according to that, we're safe, since pfSense does not use the affected fastcgi_split_path_info directive or PATH_INFO variable.

KOM

jimp

Breaking it down:

The full list of preconditions

If any one of these isn't true, then it's not vulnerable:

Nginx + php-fpm, location ~ [^/].php(/|$) must be forwarded to php-fpm (maybe the regexp can be stricter, see #1).

pfSense does use location ~ \.php$ {

The fastcgi_split_path_info directive must be there and contain a regexp starting with ^ and ending with $, so we can break it with a newline character.

pfSense does not use this directive.

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.

pfSense does not use this variable or perform the required assignment to meet this condition.

No file existence checks like try_files $uri =404 or if (-f $uri). If Nginx drops requests to non-existing scripts before FastCGI forwarding, our requests never reach php-fpm. Adding this is also the easiest way to patch.

pfSense does include try_files $uri =404; which prevents the problem.

This exploit works only for PHP 7+, but the bug itself is present in earlier versions (see below).

Current versions do run PHP 7.x.

kiokoman

laboratorio@server:~/go/bin$ ./phuip-fpizdam https://192.168.1.254:8080/index.php
2019/10/24 19:11:57 Base status code is 404
2019/10/24 19:11:58 Detect() returned error: no qsl candidates found, invulnerable or something wrong

jimp

FYI- The above is true of both the WebGUI nginx configuration and the Captive Portal configuration. Neither are vulnerable.

KOM

It's good that you have your analysis done so that you can answer the 30+ people who will post about this over the next 3 weeks...

jimp

Here, on twitter, Reddit, etc. I'm sure. I've passed along the info internally, so hopefully we can head off some of the impending tsunami.