php7-fpm vulnerability CVE-2019-11043

[dingus33]

not sure if this is the right place to post this. move it wherever you want.

anyway, if you use nginx and php7-fpm, please upgrade your php. a patch was released a few days ago.

from my understanding, the sample config for nginx from phpBB is vulnerable:

https://github.com/phpbb/phpbb/blob/mas ... ample.conf

Code: Select all

        # Pass the php scripts to fastcgi server specified in upstream declaration.
        location ~ \.php(/|$) {
            # Unmodified fastcgi_params from nginx distribution.
            include fastcgi_params;
            # Necessary for php.
            fastcgi_split_path_info ^(.+\.php)(/.*)$;
            fastcgi_param PATH_INFO $fastcgi_path_info;
            fastcgi_param SCRIPT_FILENAME $realpath_root$fastcgi_script_name;
            fastcgi_param DOCUMENT_ROOT $realpath_root;
            try_files $uri $uri/ /app.php$is_args$args;
            fastcgi_pass php;
        }

https://github.com/neex/phuip-fpizdam

read the list of preconditions there.

looks like they're satisfied. in particular, the redirect fallback in try_files still hits, so the malformed url will hit php-fpm.

[Noxwizard]

from my understanding, the sample config for nginx from phpBB is vulnerable:

read the list of preconditions there.
looks like they're satisfied. in particular, the redirect fallback in try_files still hits, so the malformed url will hit php-fpm.

That does not appear to be a sufficient condition for this exploit to succeed.

The try_files check we have in place is sufficient to stop this. If you remove that line, you do indeed become vulnerable.

[AbaddonOrmuz]

Adding =404 at the end of the try_files directive would break some URLs, I hope NAXSI does his job

[dingus33]

That does not appear to be a sufficient condition for this exploit to succeed.

The try_files check we have in place is sufficient to stop this. If you remove that line, you do indeed become vulnerable.

that seems contradictory to what's written about the exploit, e.g.:

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.

can you elaborate?

but of course everyone should just update php and move on with their lives!

[John connor]

So this just affects Nginx? What about Apache or Litespeed? And what about PHP 7.2?

Edit-

Yep. Affects PHP 7.2 https://www.symantec.com/security-cente ... eup/110608

You can't update past that since phpBB can't use PHP 7.3 right now. And 7.3 is affected as well.

[Marc]

That does not appear to be a sufficient condition for this exploit to succeed.

The try_files check we have in place is sufficient to stop this. If you remove that line, you do indeed become vulnerable.

that seems contradictory to what's written about the exploit, e.g.:

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.

can you elaborate?

but of course everyone should just update php and move on with their lives!

No, that's exactly what is written about the exploit. The sample configuration uses try_files and therefore does not fit into the preconditions necessary for it to be vulnerable to the described issue.

[dingus33]

but what's written about the exploit does not say that merely using try_files is sufficient for immunity. notably, the internal redirect fallback (the final argument to try_files) is a URI rather than a standard response code like =404 (as AbaddonOrmuz points out), so their exploit URI still hits php-fpm after breaking the fastcgi_split_path_info regex and therefore setting an empty PATH_INFO due to the php bug. it's trivial for an attacker to know you're using phpBB and nginx, and then they can (often rightly) assume you're using phpBB's sample nginx config. then they can possibly craft a suitable url for exploit, right?

see more discussion here https://bugs.php.net/bug.php?id=78599

[Noxwizard]

Before I posted my answer, I did test it first on a phpBB 3.2.8 install. Without the try_files check, the posted exploit succeeds. With the try_files check, the exploit fails. Most likely, the transfer that occurs when changing to the fallback URI changes some of the internal state that the exploit is relying one.

[John connor]

Information to those interested. https://thehackernews.com/2019/10/nginx ... cking.html