New PHP Flaw Could Let Attackers Hack Sites Running On Nginx Servers

If you’re running any PHP based website on NGINX server and
have PHP-FPM feature enabled for better performance, then beware of
a newly disclosed vulnerability that could allow unauthorized
attackers to hack your website server remotely.

The vulnerability, tracked as CVE-2019-11043, affects
websites with certain configurations of PHP-FPM that is reportedly
not uncommon in the wild and could be exploited easily as a
proof-of-concept (PoC) exploit for the flaw has already been
released publicly.

PHP-FPM is an alternative PHP FastCGI implementation that
offers advanced and highly-efficient processing for scripts written
in PHP programming language.

The main vulnerability is an “env_path_info” underflow memory
corruption issue in the PHP-FPM module, and chaining it together
with other issues could allow attackers to remotely execute
arbitrary code on vulnerable web servers.

The vulnerability was spotted by
Andrew Danau, a security researcher at Wallarm while hunting for
bugs in a Capture The Flag competition, which was then weaponized
by two of his fellow researchers, Omar Ganiev and Emil Lerner, to
develop a fully working remote code execution exploit.

Which PHP-based websites are vulnerable to hackers?

Though the publicly released PoC exploit is designed to
specifically target vulnerable servers running PHP 7+ versions, the
PHP-FPM underflow bug also affects earlier PHP versions and could
be weaponized in a different way.

In brief, a website is vulnerable, if:

• NGINX is configured to forward PHP pages requests to PHP-FPM
  processor,
• fastcgi_split_path_info directive is present in the
  configuration and includes a regular expression beginning with a
  ‘^’ symbol and ending with a ‘$’ symbol,
• PATH_INFO variable is defined with fastcgi_param
  directive,
• There are no checks like try_files $uri =404 or if (-f $uri) to
  determine whether a file exists or not.

This vulnerable NGINX and PHP-FPM configuration looks like the
following example:

Here, the fastcgi_split_path_info directive is used to split the
URL of PHP web pages into two parts, the value of one help PHP-FPM
engine to learn the script name and the other one contains its path
info.

How does PoC RCE exploit for PHP FPM work?

According to the researchers, the sample regular expression, which
defines the fastcgi_split_path_info directive, as shown, can be
manipulated by using the newline character in a way that the split
function eventually sets the path info to empty or NULL.

Now, since there is an arithmetic pointer in FPM code that
incorrectly assumes that env_path_info has a prefix equal to the
path to the php script without actually verifying the existence of
the file on the server, the issue can be exploited by an attacker
to overwrite data in the memory by requesting specially crafted
URLs of the targeted websites.

In the background, the PoC exploit [1,
2 ] researchers released chains together both
these issues to manipulate the memory and add custom php.ini
values, as shown in the screenshot, in the PHP-FPM configuration
file of a targeted server, which then eventually allows attackers
execute arbitrary code in the context of the user running the
affected application.

PHP 7 updates released to patch FPM flaw

The list of preconditions for successful exploitation, as mentioned
above, is not uncommon because the vulnerable configurations are
being used by some of the web hosting providers and available on
the Internet as part of many PHP FPM tutorials.
One such web hosting provider, Nextcloud released an advisory
yesterday warning its users that “the default Nextcloud NGINX
configuration is also vulnerable to this attack” and recommending
system administrators to take immediate actions.

A Patch for this vulnerability was released just yesterday,
almost a month after researchers reported it to the PHP developer
team.

Since the PoC exploit is already available and the patch
released just yesterday, it’s likely possible that hackers have
already started scanning the Internet for vulnerable websites.

So, users are strongly advised to update PHP to the latest
PHP
7.3.11^[4] and PHP 7.2.24^[5]. Just do it, even if you
are not using the vulnerable configuration.

^[1][3]