Bug #78840 [Ver->Csd]: imploding $GLOBALS crashes

Edit report at https://bugs.php.net/bug.php?id=78840&edit=1 ID: 78840 Updated by: cmb@php.net Reported by: syjzwjj at gmail dot com Summary: imploding $GLOBALS crashes -Status: Verified +Status: Closed Type: Bug Package: Strings related Operating System: linux PHP Version: 7.3.11 Block user comment: N Private report: N New Comment: Automatic comment on behalf of cmbecker69@gmx.de Revision: http://git.php.net/?p=php-src.git;a=commit;h=fee38633d2f81a1bc9c14093e017319b1cd6a2cf Log: Fix #78840: imploding $GLOBALS crashes Previous Comments: ------------------------------------------------------------------------ [2019-11-26 09:23:46] cmb@php.net 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 ------------------------------------------------------------------------ [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 ? ------------------------------------------------------------------------ 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