Bug #78840 [PATCH]: imploding $GLOBALS crashes

Edit report at https://bugs.php.net/bug.php?id=78840&edit=1 ID: 78840 Patch added by: cmb@php.net Reported by: syjzwjj at gmail dot com Summary: imploding $GLOBALS crashes Status: Verified Type: Bug Package: Strings related Operating System: linux PHP Version: 7.3.11 Block user comment: N Private report: N New Comment: The following pull request has been associated: Patch Name: Fix #78840: imploding $GLOBALS crashes On GitHub: https://github.com/php/php-src/pull/4947 Patch: https://github.com/php/php-src/pull/4947.patch Previous Comments: ------------------------------------------------------------------------ [2019-11-20 21:54:40] nikic@php.net To clarify, the security classification is not so much about whether the issue is "exploitable" (we generally do not care much whether something is a "benign" null pointer dereference or may allow arbitrary code execution, as long as there's some memory unsafety going on). The relevant question is whether it is *remotely* exploitable, which this issue clearly isn't. There needs to be some reasonably realistic pathway leading for a remote attacker that *cannot* already execute PHP code on the server. ------------------------------------------------------------------------ [2019-11-20 13:55:02] syjzwjj at gmail dot com I don't think so. From my perspective, you just don't want to admit the vulnerability. Firstly, the crash shows that it's not an easy null pointer deference, the crash point doesn't read/write/execute any data from zero address. And the $pc register point to an unknow address, which probably can lead to code execution and bypass any php security settings. Sencondly, even if this issue can't lead to any code execution, from the cvedetails, there're many issues which related to null pointer deference with security tag, and they all don't fit for https://wiki.php.net/security , then why you still assign cve for these issues ? Thirdly, please check https://bugs.php.net/bug.php?id=78833 and https://bugs.php.net/bug.php?id=78819, these two issues are have buffer overflow potential, which can let attacker to read/write to any address in the process. Even these issues are not security issues? The first issue even don't need any extensions of the php engine, which is more universial, Remember there're many security settings like safe_mode, open_basedir in the php, with these vulnerabilities the attacker can easily bypass these security settings. If these issues are not security issues, then can I understand that the php engine is a vulnerable engine? Because it doesn't provide any usefull security settings for the user environment and it already become a juicy target for the ctfer :) ------------------------------------------------------------------------ [2019-11-20 09:46:52] cmb@php.net > I'm confused about what kind of issue do you think are security > issue See <https://wiki.php.net/security>. Anyhow, at least one problem is that zval_get_string_func() doesn't expect an IS_INDIRECT op, causing it to return NULL, which php_implode() doesn't handle, leading to a NULL pointer dereference. ------------------------------------------------------------------------ [2019-11-20 07:09:09] syjzwjj at gmail dot com I'm confused about what kind of issue do you think are security issue ? ? ? Even the buffer overlow are not security issue in your eyes ? ------------------------------------------------------------------------ [2019-11-20 04:03:40] syjzwjj at gmail dot com sorry, the correct stacktrace should be gdb-peda$ bt #0 0x000000000073bc05 in _zval_get_string_func (op=op@entry=0x7ffff4460200) at /home/zwjj/Downloads/php-7.2.24/Zend/zend_operators.c:875 #1 0x000000000069df78 in _zval_get_string (op=0x7ffff4460200) at /home/zwjj/Downloads/php-7.2.24/Zend/zend_operators.h:273 #2 php_implode (glue=glue@entry=0x11636f0, pieces=<optimized out>, return_value=return_value@entry=0x7ffff441d0a0) at /home/zwjj/Downloads/php-7.2.24/ext/standard/string.c:1246 #3 0x000000000069e3da in zif_implode (execute_data=<optimized out>, return_value=0x7ffff441d0a0) at /home/zwjj/Downloads/php-7.2.24/ext/standard/string.c:1321 #4 0x00000000007f3837 in ZEND_DO_ICALL_SPEC_RETVAL_USED_HANDLER () at /home/zwjj/Downloads/php-7.2.24/Zend/zend_vm_execute.h:621 #5 execute_ex (ex=0x7ffff4460200) at /home/zwjj/Downloads/php-7.2.24/Zend/zend_vm_execute.h:59754 #6 0x00000000007f714e in zend_execute (op_array=0x7ffff447f2a0, op_array@entry=0x7ffff447f400, return_value=0x0, return_value@entry=0x7ffff441d030) at /home/zwjj/Downloads/php-7.2.24/Zend/zend_vm_execute.h:63780 #7 0x0000000000745633 in zend_execute_scripts (type=type@entry=0x8, retval=0x7ffff441d030, retval@entry=0x0, file_count=file_count@entry=0x3) at /home/zwjj/Downloads/php-7.2.24/Zend/zend.c:1498 #8 0x00000000006e0880 in php_execute_script (primary_file=primary_file@entry=0x7fffffffca90) at /home/zwjj/Downloads/php-7.2.24/main/main.c:2599 #9 0x00000000007f9529 in do_cli (argc=0x2, argv=0x115a220) at /home/zwjj/Downloads/php-7.2.24/sapi/cli/php_cli.c:1011 #10 0x000000000042e49c in main (argc=argc@entry=0x2, argv=0x115a220, argv@entry=0x7fffffffde88) at /home/zwjj/Downloads/php-7.2.24/sapi/cli/php_cli.c:1403 #11 0x00007ffff6f4a830 in __libc_start_main (main=0x42e020 <main>, argc=0x2, argv=0x7fffffffde88, init=<optimized out>, fini=<optimized out>, rtld_fini=<optimized out>, stack_end=0x7fffffffde78) at ../csu/libc-start.c:291 #12 0x000000000042e5b9 in _start () ------------------------------------------------------------------------ The remainder of the comments for this report are too long. To view the rest of the comments, please view the bug report online at https://bugs.php.net/bug.php?id=78840 -- Edit this bug report at https://bugs.php.net/bug.php?id=78840&edit=1