CVE-2020-28948

Edit: PoC code for this can be found at https://github.com/pear/Archive_Tar/issues/33 along with the original advisory.

An interesting vulnerability using the concepts of PHAR file deserialization as first discussed at BlackHat in this video: https://www.youtube.com/watch?v=OrEar0TiS90. For those who don’t know, the phar:// file stream handler allows opening PHAR files, which are basically PHP archive files containing a bunch of related files (mostly tends to be PHP files within the archive, but can be other things as well). Whats interesting about PHAR files is that their metadata is formed via a serialize() call when their created, and when files are extracted, unserialize() will automatically be called on that metadata string. This leads to the potential for serialization attacks even when the application doesn’t explicitly use unserialize() calls.

In this case, the Archive_Tar developers were aware of this prior research and attempted to explicitly block phar://, ../, and ..\ within any file name contained with the tar archive by performing a strpos call using these strings and erroring out if the string contained these characters. Unfortunately that check is really poor for a number of reasons.

The specific reason related to this CVE, aka CVE-2020-28948, is that users can simply use PHAR:// to bypass this check. In other words, the check performed by strpos() is not case sensitive, so one can easily bypass it by simply changing the case of the string. They could also mix the case, so an example like pHaR:// might also work.

This then allows attackers to perform attacks where they can load a local PHAR file on the target system and use a deserialization attack to perform some malicious action. Assuming an app is already extracting the contents of the TAR files locally, an attacker would simply have to upload a TAR file containing a malicious PHAR file and have the app extract and save the PHAR file locally, after which they could upload a second TAR file containing a file named PHAR://*malicious PHAR file location* and the PHP app would attempt to access and extract the local PHAR file, thereby triggering the vulnerability.

Notice that the PHAR:// file handler does not allow for accessing remote files, which is why this procedure is required.

Research into deserialization gadgets for this exploit showed that most of the potential possibilities seem mostly restricted to file operations. The PoC showed that it would be possible to delete a file using this vulnerability but I was not able to determine any other useful actions that could be performed. Potential impact would depend both on the privileges of the user running PHP as well as what operations the app was doing; again remember the program will only be able to do file operations so most likely an attacker would have to package a malicious PHP file within the PHAR archive, have that be extracted somehow along with the malicious PHAR file, and then also have a file within the TAR archive that has a filename of PHAR://*path to malicious PHAR archive that was uploaded* to form a full end to end payload and get RCE.

Overall I’d say this is an interesting bug but its exploitability is somewhat limited and depends highly on the underlying application it is used within.