CVE-2019-9675

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. Its phar extension reads and writes PHP Archive (Phar) files and plain tar and zip archives through the Phar and PharData classes.

A Buffer Overflow vulnerability (CVE-2019-9675) has been identified in the tar writer of PHP's phar extension, which allows an attacker who controls the target of a symbolic link stored in an archive that an application rewrites as a tar archive to overflow a fixed-size buffer on the stack. PHP tracks this issue as bug #77586.

Per MITRE CWE-121: A stack-based buffer overflow condition is a condition where the buffer being overwritten is allocated on the stack (i.e., is a local variable or, rarely, a parameter to a function).

This issue affects all versions of PHP before 7.1.27, PHP 7.2 before 7.2.16 and PHP 7.3 before 7.3.3, which includes 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 (ext/phar)
• 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 phar extension of all versions of 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 PHP 5.6 and 7.0 release lines, which never received the upstream fix. The CVE record, assigned by MITRE, carries no CVSS score; NVD scores it 8.1 under CVSS 3.0 (CVSS:3.0/AV:N/AC:H/PR:N/UI:N/S:U/C:H/I:H/A:H). The PHP security team classified the bug as Low severity, and the record notes the vendor's view that the link value is used only when an archive contains a symlink: "This issue allows theoretical compromise of security, but a practical attack is usually impossible."

When PHP writes a tar-based archive (for example through PharData or Phar::convertToData()), it builds a tar_header structure on the stack for each entry. For a symbolic link entry, the link target is copied into the header's linkname field, which is 100 bytes long. In PHP 5.6.40, phar_tar_writeheaders() does this:

/* calc checksum */
header.typeflag = entry->tar_type;

if (entry->link) {
    strncpy(header.linkname, entry->link, strlen(entry->link));
}

The copy length is the length of the link target, not the size of the destination field. A link target longer than 100 bytes therefore runs past linkname and over the rest of the header structure, and a long enough one past the structure itself into other stack memory. Overwriting stack memory in this way can crash PHP and may corrupt other data the function relies on.

Exploitation needs a script that writes a tar-based archive from entries that include a symbolic link whose target an attacker controls. HeroDevs' analysis lists PharData and Phar::convertToData(), under any SAPI, as the paths to this code. Applications that never write tar-based archives, or that do not process archives from untrusted sources, are not affected.

The fix copies the link target with strlcpy() bounded by the size of the field, and fails the write with an error when the target does not fit:

if (entry->link) {
    if (strlcpy(header.linkname, entry->link, sizeof(header.linkname)) >= sizeof(header.linkname)) {
        if (fp->error) {
            spprintf(fp->error, 4096, "tar-based phar \"%s\" cannot be created, link \"%s\" is too long for format", entry->phar->fname, entry->link);
        }
        return ZEND_HASH_APPLY_STOP;
    }
}

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.

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

• Jordy Zomer (finder)
• Stanislav Malyshev (remediation)