Bug #73876 [Csd]: Crash when exporting **= in expansion of assign op

From: Date: Sun, 08 Jan 2017 20:09:23 +0000
Subject: Bug #73876 [Csd]: Crash when exporting **= in expansion of assign op
References: 1  Groups: php.bugs 
Request: Send a blank email to php-bugs+get-206405@lists.php.net to get a copy of this message
Edit report at https://bugs.php.net/bug.php?id=73876&edit=1 ID: 73876 Updated by: ab@php.net Reported by: kshah at fortinet dot com Summary: Crash when exporting **= in expansion of assign op Status: Closed Type: Bug Package: Scripting Engine problem Operating System: Windows 7 SP1 PHP Version: 7.1.0 Assigned To: ab Block user comment: N Private report: N New Comment: Oh, i didn't check that :) Was tempted to do so myself as well also, because the patch was already public for many months. But posting private bug mails to the public lists IMO is a bug, not what one would expect from "private". thanks. Previous Comments: ------------------------------------------------------------------------ [2017-01-08 19:32:46] nikic@php.net Sorry, I marked this as non-private prior to reading the last comment. However, it looks like non-sec bugs are sent to the bugs list whether or not they're marked as private, so it doesn't really make a difference. Should that be changed? In any case, this is clearly not a security issue, because there is no remote exploitation vector. ------------------------------------------------------------------------ [2017-01-08 19:19:00] ab@php.net Got it. I've applied 9c3865eb6a7 which fixes the issue, was only applied to master previously. With debug symbols btw - you find them for every release or even snapshot build as a separate package on widows.php.net. Set to bug, lets keep closed till release, as there's a concern. Thanks. ------------------------------------------------------------------------ [2017-01-08 17:38:06] ab@php.net @kshah, I really doubt it is a security issue. Unpredictable behavior - yes, as from Christoph's BT it lands at the unreachable code path. Your dump also shows 0xe8cb8bd6 as possibly being wrong. So it looks more like a first best exception that that was thrown. Also, given a specific PHP code is required to be written, which doesn't depend on any data, it sounds more like a not a security issue. Thanks. ------------------------------------------------------------------------ [2017-01-06 17:19:12] cmb@php.net I can reproduce the issue with the current PHP-7.1 branch (commit c50f61b9), and get the following backtrace: ucrtbased.dll!00007ffeb7da1a05() Unknown ucrtbased.dll!00007ffeb7da1ba3() Unknown ucrtbased.dll!00007ffeb7dc2b7d() Unknown ucrtbased.dll!00007ffeb7dc8765() Unknown ucrtbased.dll!00007ffeb7dc8287() Unknown ucrtbased.dll!00007ffeb7dc6318() Unknown ucrtbased.dll!00007ffeb7dc8cef() Unknown > php7ts_debug.dll!zend_ast_export_ex(smart_str * str, _zend_ast * ast, int priority, int indent) >Line 1346 C php7ts_debug.dll!zend_ast_export_list(smart_str * str, _zend_ast_list * list, int separator, int priority, int indent) Line 754 C php7ts_debug.dll!zend_ast_export_ex(smart_str * str, _zend_ast * ast, int priority, int indent) Line 1112 C php7ts_debug.dll!zend_ast_export_ex(smart_str * str, _zend_ast * ast, int priority, int indent) Line 1323 C php7ts_debug.dll!zend_ast_export_ex(smart_str * str, _zend_ast * ast, int priority, int indent) Line 1661 C php7ts_debug.dll!zend_ast_export(const char * prefix, _zend_ast * ast, const char * suffix) Line 1713 C php7ts_debug.dll!zend_compile_assert(_znode * result, _zend_ast_list * args, _zend_string * name, _zend_function * fbc) Line 3633 C php7ts_debug.dll!zend_try_compile_special_func(_znode * result, _zend_string * lcname, _zend_ast_list * args, _zend_function * fbc, unsigned int type) Line 3662 C php7ts_debug.dll!zend_compile_call(_znode * result, _zend_ast * ast, unsigned int type) Line 3763 C php7ts_debug.dll!zend_compile_var(_znode * result, _zend_ast * ast, unsigned int type) Line 8022 C php7ts_debug.dll!zend_compile_expr(_znode * result, _zend_ast * ast) Line 7902 C php7ts_debug.dll!zend_compile_stmt(_zend_ast * ast) Line 7871 C php7ts_debug.dll!zend_compile_top_stmt(_zend_ast * ast) Line 7758 C php7ts_debug.dll!zend_compile_top_stmt(_zend_ast * ast) Line 7752 C php7ts_debug.dll!zend_compile(int type) Line 602 C php7ts_debug.dll!compile_file(_zend_file_handle * file_handle, int type) Line 635 C php7ts_debug.dll!zend_execute_scripts(int type, _zval_struct * retval, int file_count, ...) Line 1468 C php7ts_debug.dll!php_execute_script(_zend_file_handle * primary_file) Line 2537 C php.exe!do_cli(int argc, char * * argv) Line 994 C php.exe!main(int argc, char * * argv) Line 1381 C [External Code] I have not been able to reproduce the issue with current master. ------------------------------------------------------------------------ [2017-01-06 01:28:31] kshah at fortinet dot com Not a security issue? How? A DEP Violation is caused when we run the following PHP test script which thereby tries to write to NX bits on a system. This is most definitely a big security issue. Yes, I agree, PHP should be compiled with debug information (such as line numbers), but in this case the test binary was provided by PHP website which might have missed out on it. ------------------------------------------------------------------------ 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=73876 -- Edit this bug report at https://bugs.php.net/bug.php?id=73876&edit=1

« previous php.bugs (#206405) next »