|  support |  documentation |  report a bug |  advanced search |  search howto |  statistics |  random bug |  login
Request #76774 Disable the ability to use concrete types in PHAR metadata
Submitted: 2018-08-21 16:21 UTC Modified: 2019-04-17 05:38 UTC
Avg. Score:5.0 ± 0.0
Reproduced:1 of 1 (100.0%)
Same Version:1 (100.0%)
Same OS:1 (100.0%)
From: korvinszanto at gmail dot com Assigned: bishop (profile)
Status: Assigned Package: PHAR related
PHP Version: 7.2.9 OS: Ubuntu 18.04
Private report: No CVE-ID: None
Have you experienced this issue?
Rate the importance of this bug to you:

 [2018-08-21 16:21 UTC] korvinszanto at gmail dot com
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

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:

class Foo {
  public function __wakeup() {

$file = './test.phar';
if (!file_exists($file)) {

  $p = new Phar($file);


  // pointing main file which requires all classes
  $p->setMetadata(new Foo());

// Trigger unsafe deserialization

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


Add a Patch

Pull Requests

Add a Pull Request


AllCommentsChangesGit/SVN commitsRelated reports
 [2019-04-17 05:38 UTC]
-Status: Open +Status: Assigned -Assigned To: +Assigned To: bishop
 [2019-04-17 05:40 UTC]
As described on the PHP internals mailing list[1], phar deserializes header metadata upon opening the phar stream. If the metadata contains a serialized value that's meant to act maliciously[2], there's no way for the caller to prevent the malice[3].

The immediate mitigation is to defer metadata deserialization until such time as it's explicitly needed -- eg Phar::getMetadata(). Additionally, update the documentation to note the risk of calling getMetadata on a phar from untrusted sources.

Future mitigations may make it possible to treat phar from untrusted sources with more care. Any such work, however, is out of scope for this ticket.

 [2019-04-17 05:41 UTC]
// Original code by Sam Thomas - @_s_n_t
// @see's-A-PHP-Unserialization-Vulnerability-Jim-But-Not-As-We-....pdf

class TestObject {
  function __destruct() {
    echo "DESTRUCT!\n";

$phar = new Phar("phar.phar");
$phar->setStub("<?php __HALT_COMPILER(); ?>");
$o = new TestObject();

echo(file_get_contents("phar://phar.phar/test.txt")); // DESTRUCT!
PHP Copyright © 2001-2020 The PHP Group
All rights reserved.
Last updated: Fri Jul 10 00:01:26 2020 UTC