Req #76774 [Opn->Asn]: Disable the ability to use concrete types in PHAR metadata

Edit report at https://bugs.php.net/bug.php?id=76774&edit=1 ID: 76774 Updated by: bishop@php.net Reported by: korvinszanto at gmail dot com Summary: Disable the ability to use concrete types in PHAR metadata -Status: Open +Status: Assigned Type: Feature/Change Request Package: PHAR related Operating System: Ubuntu 18.04 PHP Version: 7.2.9 -Assigned To: +Assigned To: bishop Block user comment: N Private report: N Previous Comments: ------------------------------------------------------------------------ [2018-08-21 16:21:54] korvinszanto at gmail dot com Description: ------------ It's currently possible to serialize concrete types in a phar metadata, which opens us up to the potential for deserialization attacks through gadget chains. Since PHAR files can serialize concrete types, they can serialize chains of objects that, when deserialized, fire __construct __destruct and __wakeup. This is an issue largely because PHP will automatically deseralize this payload in the following case: file_exists('phar://path/to/phar') which has cauused RCE in a couple projects in the wild including Typo3 https://typo3.org/security/advisory/typo3-core-sa-2018-002/ I propose that we disable the ability to have concrete types included in the serialized metadata by providing an empty classlist to the unserialize call in the PHAR package. This will support the real cases we see in the wild of metadata usage which is only array key values. Test script: --------------- <?php class Foo { public function __wakeup() { die('FIRED WAKEUP UNEXPECTEDLY'); } } $file = './test.phar'; if (!file_exists($file)) { $p = new Phar($file); $p->setStub(Phar::createDefaultStub(__FILE__)); $p->addFile(__FILE__); // pointing main file which requires all classes $p->setMetadata(new Foo()); $p->compress(Phar::GZ); } // Trigger unsafe deserialization file_exists($file); Expected result: ---------------- File_exists currently loads the entire metadata for the phar. If this is intended, I'd expect the metadata to safely unserialize without fire any magic methods. Actual result: -------------- Magic methods get fired ------------------------------------------------------------------------ -- Edit this bug report at https://bugs.php.net/bug.php?id=76774&edit=1