|  support |  documentation |  report a bug |  advanced search |  search howto |  statistics |  random bug |  login
Sec Bug #73764 Crash while loading hostile phar archive
Submitted: 2016-12-16 21:22 UTC Modified: 2017-01-25 11:10 UTC
From: eyal dot itkin at gmail dot com Assigned: stas (profile)
Status: Closed Package: PHAR related
PHP Version: 5.6.29 OS:
Private report: No CVE-ID: 2016-10159
View Add Comment Developer Edit
Welcome! If you don't have a Git account, you can't do anything here.
You can add a comment by following this link or if you reported this bug, you can edit this bug over here.
Block user comment
Status: Assign to:
Bug Type:
From: eyal dot itkin at gmail dot com
New email:
PHP Version: OS:


 [2016-12-16 21:22 UTC] eyal dot itkin at gmail dot com
Loading a hostile phar archive can cause an extensive memory allocation, that will trigger a fatal PHP error on 32 bit computers.

1) entry.filename_len is 4 bytes
2) value of 2 ** 32 - x can trigger an integer-overflow in the sanity check ( 0 < x <= 20):
if(entry.filename_len - 20 > (size_t)(endbuffer - buffer)){
3) later the call to "pestrndup" will crash:
pestrndup(buffer, entry.filename_len, entry.is_persistent);

The fix should be in 2 separate checks:
1) update the 1st check inside the loop from 4 to 24 (full entry size):
if (buffer + 24 < endbuffer){
2) avoid integer-overflow in the sanity check (20 because buffer was advanced by 4 already):
if(entry.filename_len > (size_t)(endbuffer - buffer) - 20){

Test script:
	$p = Phar::LoadPhar('example_hostile.phar', 'alias.phar');
	echo "Loaded the phar archive\n";

Expected result:
The script should print the message

Actual result:

mmap() failed: [22] Invalid argument

mmap() failed: [22] Invalid argument
PHP Fatal error:  Out of memory (allocated 2097152) (tried to allocate 4294967277 bytes) in XXX on line 2


Add a Patch

Pull Requests

Add a Pull Request


AllCommentsChangesGit/SVN commitsRelated reports
 [2016-12-27 07:04 UTC]
-Status: Open +Status: Feedback
 [2016-12-27 07:04 UTC]
Please provide example_hostile.phar
 [2016-12-27 09:05 UTC] eyal dot itkin at gmail dot com
-Status: Feedback +Status: Open
 [2016-12-27 09:05 UTC] eyal dot itkin at gmail dot com
Uploaded the example_hostile.phar (+ the python script than generated it) to this link:
 [2016-12-30 23:41 UTC]
-Assigned To: +Assigned To: stas
 [2016-12-30 23:41 UTC]
The fix is in security repo as ca46d0acbce55019b970fcd4c1e8a10edfdded93 and in

Please verify.
 [2016-12-30 23:59 UTC]
-PHP Version: 7.1.0 +PHP Version: 5.6.29
 [2016-12-31 01:01 UTC]
-CVE-ID: +CVE-ID: needed
 [2016-12-31 08:30 UTC] eyal dot itkin at gmail dot com
I verified the fix in the repository, and it will indeed solve this vulnerability.

Wanted to ask why did the PHP version changed to 5.X instead of 7.X? The vulnerability was found (and reproduced) in the latest PHP version, and it also (but not only) applies to previous versions.
 [2017-01-01 02:50 UTC]
Due to the nature of PHP branches and how bugs are fixed in PHP, in the bug is in 5.6, it's most likely also in 7.x, but the reverse is frequently not true. Thus, the lowest branch having the problem is used. If the bug is 5.x specific, but not present in 7.x, it is noted in the bug (and then manual merge procedure is needed).
 [2017-01-03 05:26 UTC]
-Status: Assigned +Status: Closed
 [2017-01-03 05:26 UTC]
The fix for this bug has been committed.

Snapshots of the sources are packaged every three hours; this change
will be in the next snapshot. You can grab the snapshot at

 For Windows:
Thank you for the report, and for helping us make PHP better.

 [2017-01-25 11:10 UTC]
-CVE-ID: needed +CVE-ID: 2016-10159
PHP Copyright © 2001-2018 The PHP Group
All rights reserved.
Last updated: Sun Nov 19 01:31:42 2017 UTC