|
php.net | support | documentation | report a bug | advanced search | search howto | statistics | random bug | login |
PatchesPull RequestsHistoryAllCommentsChangesGit/SVN commits
[2016-12-27 07:05 UTC] stas@php.net
-Status: Open
+Status: Feedback
[2016-12-27 07:05 UTC] stas@php.net
[2016-12-27 09:04 UTC] eyal dot itkin at gmail dot com
-Status: Feedback
+Status: Open
[2016-12-27 09:04 UTC] eyal dot itkin at gmail dot com
[2016-12-31 00:07 UTC] stas@php.net
-Status: Open
+Status: Feedback
[2016-12-31 00:07 UTC] stas@php.net
[2016-12-31 08:56 UTC] eyal dot itkin at gmail dot com
-Status: Feedback
+Status: Open
[2016-12-31 08:56 UTC] eyal dot itkin at gmail dot com
[2016-12-31 09:19 UTC] stas@php.net
-Status: Open
+Status: Feedback
[2016-12-31 09:19 UTC] stas@php.net
[2016-12-31 10:29 UTC] eyal dot itkin at gmail dot com
-Status: Feedback
+Status: Open
[2016-12-31 10:29 UTC] eyal dot itkin at gmail dot com
[2017-01-01 02:48 UTC] stas@php.net
-PHP Version: 7.1.0
+PHP Version: 5.6.29
-Assigned To:
+Assigned To: stas
[2017-01-01 02:48 UTC] stas@php.net
[2017-01-01 04:02 UTC] eyal dot itkin at gmail dot com
[2017-01-03 05:11 UTC] stas@php.net
[2017-01-03 05:11 UTC] stas@php.net
-Status: Assigned
+Status: Closed
[2017-01-03 05:26 UTC] stas@php.net
[2017-01-05 23:57 UTC] tyrael@php.net
-Summary: Seg fault when loading hostile phar
+Summary: Segfault when loading hostile phar
[2017-01-06 00:00 UTC] tyrael@php.net
-Summary: Segfault when loading hostile phar
+Summary: Seg fault when loading hostile phar
[2017-02-13 00:54 UTC] stas@php.net
-CVE-ID:
+CVE-ID: needed
[2017-07-12 10:41 UTC] henri at nerv dot fi
[2017-07-12 17:09 UTC] stas@php.net
-CVE-ID: needed
+CVE-ID: 2017-11147
|
|||||||||||||||||||||||||||
Copyright © 2001-2025 The PHP GroupAll rights reserved. |
Last updated: Sun Oct 26 09:00:01 2025 UTC |
Description: ------------ phar.c - phar_parse_pharfile() has insufficient sanity checks on the entry data. A hostile phar archive can lead the parser to access memory out of the allocated buffer, resulting in a crash. The for loop that parses the manifest entries does not properly checks that the metadata_len 4 bytes field is inside the buffer, enabling a huge page aligned archive to trigger an out-of-page read, causing a segmentation fault - as presented in the attached trace. The proposed fix is to add a check before reading this length field (just like the check in the start of the for loop): if ( 4 > (size_t)(endbuffer - buffer)) { <report error> } This report is somewhat connected to report #73764, and both should probably be fixed together so to avoid confusion. Test script: --------------- <?php $p = new Phar('example_hostile.phar', 0); echo "Loaded the phar archive\n"; ?> Expected result: ---------------- no crash, calling the echo with the specified message as intended Actual result: -------------- segmentation fault. (gdb) bt #0 0xb4c7cb56 in ?? () from /usr/lib/php/20151012/phar.so #1 0xb4c7ebce in phar_create_or_parse_filename () from /usr/lib/php/20151012/phar.so #2 0xb4c7f8b7 in phar_open_or_create_filename () from /usr/lib/php/20151012/phar.so #3 0xb4c8120e in zim_Phar___construct () from /usr/lib/php/20151012/phar.so #4 0x80348662 in execute_internal () #5 0x802a1dce in dtrace_execute_internal () #6 0x80339f65 in ?? () #7 0x802f26da in execute_ex () #8 0x802a1c35 in dtrace_execute_ex () #9 0x8034a1b6 in zend_execute () #10 0x802b210d in zend_execute_scripts () #11 0x80251054 in php_execute_script () #12 0x8034c01f in ?? () #13 0x8012b64f in main () (gdb) info reg eax 0xa8200000 -1474297856 ecx 0x0 0 edx 0xb49fffec -1264582676 ebx 0xb4ca6c40 -1261802432 esp 0xbfeee240 0xbfeee240 ebp 0xb5274000 0xb5274000 esi 0x640001b 104857627 edi 0xb4a00000 -1264582656 eip 0xb4c7cb56 0xb4c7cb56 eflags 0x210246 [ PF ZF IF RF ID ] cs 0x73 115 ss 0x7b 123 ds 0x7b 123 es 0x7b 123 fs 0x0 0 gs 0x33 51