NGINX.COM

NGINX is now part of F5. See why we’re better together.

Addressing the PHP-FPM Vulnerability (CVE-2019-11043) with NGINX

A recently reported vulnerability, tracked as CVE-2019-11043, can affect websites that use PHP‑FPM to execute PHP pages. PHP‑FPM usage is particularly common at NGINX‑powered websites because NGINX does not have an in‑process PHP runtime. Instead, NGINX acts as a reverse proxy for application servers and process managers such as PHP‑FPM.

The vulnerability lies in PHP‑FPM itself, not NGINX, so the only guaranteed solution is to upgrade to the patched release (or later) of your PHP version: PHP 7.1.33, PHP 7.2.24, or PHP 7.3.11.

What Is the Nature of the Vulnerability?

NGINX communicates with PHP‑FPM using the FastCGI protocol. Each FastCGI message contains a set of environment variables. One of these, PATH_INFO, is derived from other request parameters. If its value is unexpectedly empty, this can ultimately cause memory corruption in the PHP‑FPM binary. It is possible to exploit this situation and make the PHP‑FPM binary run arbitrary commands on the local server.

This vulnerability can be triggered by a common NGINX configuration, whereby NGINX uses a regular expression in the fastcgi_split_path_info directive to split the request URI into two parts. One way to trigger the vulnerability is to embed a line break (%0a) or carriage return (%0d) character into the request URI, which is then not correctly handled by the regular expression.

Mitigating Against the Vulnerability

As mentioned above, the only certain way to address this vulnerability is to upgrade to the patched release (or later) of your PHP version: PHP 7.1.33, PHP 7.2.24, or PHP 7.3.11.

If you are not able to upgrade your PHP binary immediately, there are several partial mitigations you can make:

  1. Various sources have suggested to add a try_files directive to the NGINX configuration to verify that the $uri variable resolves to a file (the PHP script) and reject the request with code 404 (Not Found) if not:

    location ~ [^/]\.php(/|$) {
        fastcgi_split_path_info ^(.+?\.php)(/.*)$;
        fastcgi_param           PATH_INFO $fastcgi_path_info;
        try_files               $uri =404;
        #...
    }

    Note that this mitigation only works if NGINX and PHP‑FPM share the same docroot on the same host.

    PHP configurations vary depending on the needs of the upstream application. Please test changes like this to verify they do not impact your application.

  2. Use F5 BIG-IP ASM (Application Security Manager) to protect the application. The existing “Command Execution” and “Server Side Code Injection” signature sets include attack signatures that will block most attempts to discover and exploit this PHP-FPM vulnerability, and the F5 Security Team will shortly release an additional signature that is specific to this vulnerability in an upcoming update.

  3. Add a ModSecurity rule to block requests that contain the suspicious %0a or %0d character:

    SecRule REQUEST_URI "@rx %0(a|A|d|D)" "id:1,phase:1,t:lowercase,deny"

    This solution is described in the Wallarm’s original report about the vulnerability; it may cause false positives and an attacker might still find other ways to exploit the vulnerability.

Using a Different PHP Process Manager

Rather than rely on PHP‑FPM, you can use NGINX Unit to run your PHP applications. NGINX Unit is a high‑performance, open source application server and process manager that supports numerous languages and frameworks in addition to PHP. It can auto‑scale PHP applications in response to load, and concurrently run applications that use different PHP runtimes. We provide binaries, source, and Docker images for free.

See the NGINX Unit documentation for instructions on configuring and operating NGINX Unit for WordPress, a popular, high‑traffic, PHP‑powered application. The deployment takes advantage of the support for serving static files in NGINX Unit 1.11.0 and later.

Cover image
Monolith to Microservices

Free ebook that goes deep on transitioning an existing monolithic architecture to microservices

Tags

No More Tags to display