CVE-2019-9637

Overview

PHP is a general-purpose scripting language used mostly for web development. It runs behind web servers through server APIs such as Apache mod_php and PHP-FPM, and powers content management systems and frameworks such as WordPress, Drupal, Moodle and Laravel.

An Information Exposure vulnerability (CVE-2019-9637) has been identified in PHP's rename() implementation for local files, which allows other local users on the same host to read, or possibly write, a file while PHP moves it to another file system, because the copy briefly exists with permissions taken from the default umask rather than those of the original file. PHP tracks this issue as bug #77630.

Per MITRE CWE-732: The product specifies permissions for a security-critical resource in a way that allows that resource to be read or modified by unintended actors.

This issue affects PHP before 7.1.27, PHP 7.2 before 7.2.16 and PHP 7.3 before 7.3.3, including the End-of-Life release lines PHP 5.6 and 7.0 through their final releases (5.6.40 and 7.0.33).

Details

Module Info

• Product: PHP
• Affected packages: php-src (main/streams)
• Affected versions: <7.1.27, >=7.2.0 <7.2.16, >=7.3.0 <7.3.3
• GitHub repository: https://github.com/php/php-src
• Published packages: https://www.php.net/downloads
• Package manager: N/A
• Fixed in:
  • OSS PHP 7.1.27, 7.2.16, 7.3.3
  • NES for PHP 5.6.1 (based on PHP 5.6.40)

Vulnerability Info

This High-severity vulnerability is found in the plain files stream wrapper of PHP before 7.1.27, 7.2 before 7.2.16 and 7.3 before 7.3.3, and in the End-of-Life PHP 5.6 and 7.0 release lines, which never received the upstream fix. The CVE record, published by MITRE, carries no CVSS score; NVD scores it 7.5 under CVSS 3.0 (CVSS:3.0/AV:N/AC:L/PR:N/UI:N/S:U/C:H/I:N/A:N).

When rename() moves a file within one file system, the operating system renames it in place. When the target is on another file system, the system call fails with EXDEV and PHP falls back to copying the file and deleting the original. In PHP 7.1.26, that fallback begins:

if (errno == EXDEV) {
    zend_stat_t sb;
    if (php_copy_file(url_from, url_to) == SUCCESS) {
        if (VCWD_STAT(url_from, &sb) == 0) {
# if !defined(TSRM_WIN32) && !defined(NETWARE)
            if (VCWD_CHMOD(url_to, sb.st_mode)) {

The copy is created with the permissions that the process umask allows, and only after the copy finishes does PHP apply the original file's mode and then its owner and group. Until then, other local users may be able to open the copy with those default permissions, read it, or write to it if the umask allows. A process that opens the file during that window can keep its open handle after the mode changes.

Exploitation needs a multi-user host where another local account can reach the target directory, and a script that renames a file across file systems, for example from an upload or temporary directory on another mount, under any server API. The attacker must act while the copy is in progress. Hosts where the source and target are on the same file system, or where no untrusted local users exist, are not exposed.

The fix sets the umask to 077 for the duration of the copy, so the new file is readable only by its owner, then sets the owner and group before the mode so that group access is granted only to the intended group. As the upstream commit notes, the umask is process-wide, so thread-safe (ZTS) builds keep the previous behavior:

# if !defined(ZTS) && !defined(TSRM_WIN32) && !defined(NETWARE)
            /* not sure what to do in ZTS case, umask is not thread-safe */
            int oldmask = umask(077);
# endif
            int success = 0;
            if (php_copy_file(url_from, url_to) == SUCCESS) {

Mitigation

The PHP project publishes security fixes only for its supported release lines. PHP 5.6 and 7.0 are End-of-Life and will not receive any public updates to address this issue.

Until an upgrade is possible, keep the source and target of rename() on the same file system, so that the copy fallback is never used.

Users of the affected components should apply one of the following mitigations:

• Upgrade to PHP 7.1.27, 7.2.16, 7.3.3, or later.
• Leverage a commercial support partner like HeroDevs (NES for PHP) for post-EOL security support.

Credits

• manabu.matsui (finder)
• Stanislav Malyshev (remediation)