PHP :: Bug #78840 :: imploding $GLOBALS crashes

Bug #78840	imploding $GLOBALS crashes
Submitted:	2019-11-20 03:40 UTC	Modified:	2019-11-27 08:36 UTC
From:	syjzwjj at gmail dot com	Assigned:	cmb (profile)
Status:	Closed	Package:	Strings related
PHP Version:	7.3.11	OS:	linux
Private report:	No	CVE-ID:	None

View Developer Edit

Welcome! If you don't have a Git account, you can't do anything here.
If you reported this bug, you can edit this bug over here.

php.net Username: php.net Password:

Quick Fix:	(description)
	Block user comment
Status:		Assign to:
Package:
Bug Type:
Summary:
From:	syjzwjj at gmail dot com
New email:
PHP Version:		OS:

New/Additional Comment:

[2019-11-20 03:40 UTC] syjzwjj at gmail dot com

Description:
------------
php doesn't check well on implode function, which can cause type confusion.

Test script:
---------------
<?php
   echo implode($GLOBALS, $b);
?>

Expected result:
----------------
engine operate normal

Actual result:
--------------
engine crash with backtrace below

[----------------------------------registers-----------------------------------]
RAX: 0xff94cf3cff94cf9c 
RBX: 0x7ffff4460200 --> 0x7ffff441d080 --> 0x0 
RCX: 0x0 
RDX: 0xdef778 --> 0xff94c2c8ff94c2c8 
RSI: 0x7fffffffa340 --> 0x2 
RDI: 0x7ffff4460200 --> 0x7ffff441d080 --> 0x0 
RBP: 0x7ffff447a0a0 --> 0x7ffff4403600 --> 0x600000001 
RSP: 0x7fffffffa330 --> 0x0 
RIP: 0x73bc05 (<_zval_get_string_func+581>:	call   rax)
R8 : 0x7068702e326873 ('sh2.php')
R9 : 0x7ffff4460220 --> 0x0 
R10: 0x0 
R11: 0x4f ('O')
R12: 0x11636f0 --> 0x70600000001 
R13: 0x24 ('$')
R14: 0x7ffff447a0d8 --> 0x7ffff4403680 --> 0x600000001 
R15: 0x7ffff4460200 --> 0x7ffff441d080 --> 0x0
EFLAGS: 0x10286 (carry PARITY adjust zero SIGN trap INTERRUPT direction overflow)
[-------------------------------------code-------------------------------------]
   0x73bbf7 <_zval_get_string_func+567>:	je     0x73ba04 <_zval_get_string_func+68>
   0x73bbfd <_zval_get_string_func+573>:	lea    rsi,[rsp+0x10]
   0x73bc02 <_zval_get_string_func+578>:	mov    rdi,rbx
=> 0x73bc05 <_zval_get_string_func+581>:	call   rax
   0x73bc07 <_zval_get_string_func+583>:	mov    rbp,rax
   0x73bc0a <_zval_get_string_func+586>:	movzx  eax,BYTE PTR [rax+0x8]
   0x73bc0e <_zval_get_string_func+590>:	cmp    al,0x8
   0x73bc10 <_zval_get_string_func+592>:	je     0x73b9f9 <_zval_get_string_func+57>
Guessed arguments:
arg[0]: 0x7ffff4460200 --> 0x7ffff441d080 --> 0x0 
arg[1]: 0x7fffffffa340 --> 0x2 
[------------------------------------stack-------------------------------------]
0000| 0x7fffffffa330 --> 0x0 
0008| 0x7fffffffa338 --> 0x0 
0016| 0x7fffffffa340 --> 0x2 
0024| 0x7fffffffa348 --> 0xe4b1cd2c4529f500 
0032| 0x7fffffffa350 --> 0x0 
0040| 0x7fffffffa358 --> 0x0 
0048| 0x7fffffffa360 --> 0x1164998 --> 0x62 ('b')
0056| 0x7fffffffa368 --> 0x1142b10 --> 0x800700000001 
[------------------------------------------------------------------------------]
Legend: code, data, rodata, value
Stopped reason: SIGSEGV
0x000000000073bc05 in _zval_get_string_func (op=op@entry=0x7ffff4460200)
    at /home/zwjj/Downloads/php-7.2.24/Zend/zend_operators.c:875
875					zval *z = Z_OBJ_HT_P(op)->get(op, &tmp);

Patches

Pull Requests

Pull requests:

Fix #78840: imploding $GLOBALS crashes (php-src/4947)

History

AllCommentsChangesGit/SVN commitsRelated reports

[2019-11-20 03:41 UTC] syjzwjj at gmail dot com

php main stable versions 7.1.33, 7.2.24, 7.3.11 are all affected.

[2019-11-20 03:53 UTC] syjzwjj at gmail dot com

-Summary: php implode function exists a type confusion vulnerability +Summary: php string related function exists a type confusion vulnerability -Package: Arrays related +Package: Strings related

[2019-11-20 03:53 UTC] syjzwjj at gmail dot com

stack trace are below

gdb-peda$ bt
#0  0x000000000073bc05 in _zval_get_string_func (op=0x7ffff4460200)
    at /home/zwjj/Downloads/php-7.2.24/Zend/zend_operators.c:875
#1  0x000000000069f3f9 in _zval_get_string (op=<optimized out>)
    at /home/zwjj/Downloads/php-7.2.24/Zend/zend_operators.h:273
#2  php_str_replace_in_subject (search=search@entry=0x7ffff441d3e0, 
    replace=replace@entry=0x7ffff441d3f0, subject=<optimized out>, result=result@entry=0x7fffffffa3e0, 
    case_sensitivity=case_sensitivity@entry=0x1)
    at /home/zwjj/Downloads/php-7.2.24/ext/standard/string.c:3950
#3  0x000000000069fc61 in php_str_replace_common (execute_data=0x7ffff441d390, 
    return_value=0x7ffff441d2f0, case_sensitivity=0x1)
    at /home/zwjj/Downloads/php-7.2.24/ext/standard/string.c:4130
#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=0x7ffff44910e0, 
    return_value=0x0, return_value@entry=0x7ffff441d240)
    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=0x7ffff441d240, 
    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 ()

[2019-11-20 04:03 UTC] 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 ()

[2019-11-20 06:47 UTC] stas@php.net

-Type: Security +Type: Bug

[2019-11-20 07:09 UTC] 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 09:46 UTC] cmb@php.net

-Status: Open +Status: Verified

[2019-11-20 09:46 UTC] 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 13:55 UTC] 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 21:54 UTC] 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-26 09:23 UTC] cmb@php.net

-Summary: php string related function exists a type confusion vulnerability +Summary: imploding $GLOBALS crashes

[2019-11-26 09:23 UTC] 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-27 08:35 UTC] cmb@php.net

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

[2019-11-27 08:35 UTC] cmb@php.net

-Status: Verified +Status: Closed

[2019-11-27 08:36 UTC] cmb@php.net

-Assigned To: +Assigned To: cmb

	php.net \| support \| documentation \| report a bug \| advanced search \| search howto \| statistics \| random bug \| login
go to bug id or search bugs for


Copyright © 2001-2024 The PHP Group All rights reserved.	Last updated: Thu Nov 21 11:01:29 2024 UTC