CVE-2020-28949

Archive_Tar through 1.4.10 has :// filename sanitization only to address phar attacks, and thus any other stream-wrapper attack (such as file:// to overwrite files) can still succeed.

Recent assessments:

gwillcox-r7 at January 15, 2021 8:42pm UTC reported:

Original advisory and PoC can be found at <https://github.com/pear/Archive_Tar/issues/33&gt;

This vulnerability is very similar to CVE-2020-28948, with a couple of key differences. In the case of CVE-2020-28948, the root issue was that the code within Archive_Tar didn’t use case sensitive checks to ensure file names didn’t start with phar://. Here the issue is the same however it stems from a lack of checks. More specifically as mentioned in my writeup on CVE-2020-28948, Archive_Tar prior to 1.4.11 checked, using strpos(), that filenames within a TAR archive did not start with the characters phar:// and did not contain the characters ../ or ..\.

Notice however that there is a problem here: we can still use any other file stream wrapper other than the phar:// file handler within a file name to trigger the corresponding wrapper handler. A full list of PHP file stream wrappers can be found at <https://www.php.net/manual/en/wrappers.php&gt;.

Looking at these stream wrappers reveals there are a few that might help with file writes. In fact, as shown in the PoC at <https://github.com/pear/Archive_Tar/issues/33&gt;, if one creates a file within a TAR archive with a name such as file:///etc/passwd, then when the TAR archive is extracted, the corresponding file, which in this case would be /etc/passwd, will be overwritten with attacker controlled contents, assuming the user that PHP is running as has permissions to create or overwrite that file.

This leads to an arbitrary file upload vulnerability whereby an attacker could potentially overwrite existing files with arbitrary content. The attacker would however need to know the exact path on disk to the file that they wished to write: remember that ..\ and ../ are not allowed in filenames and even if they were, the file:// stream wrapper requires the use of absolute paths.

Again as noted in my writeup on CVE-2020-28948, this bug entirely depends on the fact that a vulnerable application makes use of this library and also extracts the contents of the TAR file as part of its operations. If the application only allows TAR file uploads but it doesn’t actually try to extract the contents of the TAR file as part of its operations, then this vulnerability will never be triggered.

That being said assuming an attacker does know the right path and the application is set up in to extract TAR files, then this can easily lead to RCE via overwriting existing PHP files on the target system.

Assessed Attacker Value: 4
Assessed Attacker Value: 4Assessed Attacker Value: 4