If you use a PHP-based website on an NGINX server and you have PHP-FPM turned on for better performance, watch out for a newly discovered vulnerability that could allow unauthorized users to hack your website’s server remotely.
The vulnerability discovered as CVE-2019-11043 concerns websites with certain PHP-FPM configurations, which are reported to be not unusual in nature and can be easily exploited after using the testing concept (PoC) for a defect already published.
PHP-FPM is an alternative implementation of PHP FastCGI, which offers advanced and highly efficient processing of scripts written in the PHP programming language.
The main vulnerability is the problem of corrupted invalid memory env_path_info in the PHP-FPM module, and its association with other problems could allow attackers to remotely execute arbitrary code on vulnerable web servers.
This vulnerability was discovered by Andrew Danau, a Wallarm security researcher, while searching for bugs in the Capture The Flag contest, which was then armed by two of his research colleagues, Omar Ganiev and Emil Lerner, to develop an exploit for remote code execution. ,
PHP sites are vulnerable to hackers?
Although publicly available PoC exploits are designed specifically for vulnerable servers running versions of PHP 7+, the overflow error PHP-FPM also affects previous versions of PHP and may be enabled differently.
In short, a site is vulnerable if:
- NGINX is configured to forward requests to PHP pages to the PHP-FPM processor
- the fastcgi_split_path_info directive is present in the configuration and contains a regular expression that begins with the character “^” and ends with the character “$”,
- The PATH_INFO variable is defined using the fastcgi_param directive,
- There are no controls like try_files $ uri = 404 or if (-f $ uri) to determine if a file exists.
This vulnerable configuration of NGINX and PHP-FPM is as follows:
Here, the fastcgi_split_path_info directive is used to separate the URLs of PHP web pages into two parts: the value of the PHP-FPM mechanism that helps to find out the name of the script, and the other contains information about its path.
How does PoC RCE work for PHP FPM?
According to the researchers, an example of a regular expression that defines the fastcgi_split_path_info directive, as shown, can be controlled using a newline, so the split function ultimately makes the path information empty.
Subsequently, since the FPM code has an arithmetic pointer, which mistakenly assumes that env_path_info has a prefix equal to the path of the PHP script, without actually checking the existence of the file on the server, an attacker could use this problem to overwrite data in memory requesting specially crafted URLs Destination site addresses.
In the background, PoC researchers [1 (PHuiP-FPizdaM), 2] researchers released both of these problems together to manipulate memory and add custom php.ini values, as shown in the screenshot, in the target server’s PHP-FPM configuration file, which allows attackers execute arbitrary code using a web shell.
“Using a carefully selected URL path length and a query string, an attacker can force path_info to point exactly to the first byte of the _fcgi_data_seg structure. Putting a zero in it, the field `char * pos moves backward` and after FCGI_PUTENV overwrite some data (including other fast cgi variables) with the path to the script, “the researchers said in an error report presented in the PHP project.
“Using this technique, I was able to create the fcgi variable PHP_VALUE false and then use a chain of carefully selected configuration values to run the code.”
PHP 7 Updates Released to Fix FPM Error
A list of prerequisites for successful operation, as mentioned above, is not uncommon, as vulnerable configurations are used by some web hosting providers and are available on the Internet as part of many PHP FPM tutorials.
One of these interested hosting providers is Nextcloud, which yesterday issued a warning user that “even the Nextcloud NGINX configuration is vulnerable to this attack by default,” and recommends that system administrators take immediate action.
A patch for this vulnerability was released only yesterday, almost a month after researchers reported this to the PHP development team.
Since the PoC exploit is already available and the patch was released only yesterday, it is likely that hackers have already begun to scan the Internet for vulnerable websites.
Therefore, users are advised to upgrade PHP to the latest version of PHP 7.3.11 and PHP 7.2.24. Just do it even if you are not using a vulnerable configuration.