php.net |  support |  documentation |  report a bug |  advanced search |  search howto |  statistics |  random bug |  login

go to bug id or search bugs for

Bug #75840 when i load COM('WScript.shell') and call exec('cmd.exe /c whoami') to execute
Submitted: 2018-01-18 09:10 UTC Modified: 2018-12-14 21:07 UTC
Votes:2
Avg. Score:3.5 ± 0.5
Reproduced:2 of 2 (100.0%)
Same Version:1 (50.0%)
Same OS:1 (50.0%)
From: zhang_xiaobao at venustech dot com dot cn Assigned:
Status: No Feedback Package: COM related
PHP Version: 7.0.27 OS: windows
Private report: No CVE-ID: None
View Developer Edit
 [2018-01-18 09:10 UTC] zhang_xiaobao at venustech dot com dot cn 
Description:
------------
<?php
$wsh = new COM('WScript.shell');
$exec = $wsh->exec('cmd.exe /c whoami');
$stdout = $exec->StdOut();
$stroutput = $stdout->ReadAll();
echo $stroutput;
?>

Test script:
---------------
<?php
$wsh = new COM('WScript.shell');
$exec = $wsh->exec('cmd.exe /c whoami');
$stdout = $exec->StdOut();
$stroutput = $stdout->ReadAll();
echo $stroutput;
?>

Expected result:
----------------
1. First of all, add extension=php_com_dotnet.dll in php.ini.
2. when i load COM('WScript.shell') and call exec('cmd.exe /c whoami') to execute system command,the inside of the com waits for the process to exit,
as the same time,the com is freed by other modules,when the cmd.exe exited, the thread who suspend with the waitformultipleobjects function is activated.
but the eip is not invalid,because of the memory is free.

Actual result:
--------------
It cause the process of httpd.exe to crash.

Patches

Pull Requests

History

AllCommentsChangesGit/SVN commitsRelated reports
 [2018-01-20 19:29 UTC] ab@php.net
-Status: Open +Status: Feedback
 [2018-01-20 19:29 UTC] ab@php.net 
Thanks for the report. I currently don't reproduce any crash with your code. Could you please provide a corresponding backtrace and/or crash dump? Modules are only freed at the process exit, mpm_winnt is only one child per server. Is that about mpm_winnt or fcgi?

Disregarding the possible crash, I'd not see this as a security issue.

Thanks.
 [2018-01-20 22:12 UTC] stas@php.net
-Type: Security +Type: Bug
 [2018-01-22 05:31 UTC] zhang_xiaobao at venustech dot com dot cn
-Status: Feedback +Status: Open
 [2018-01-22 05:31 UTC] zhang_xiaobao at venustech dot com dot cn 
Because of the work mailbox has an attachment size limit,I will send process dump information for you through my other mailbox(1486805345@qq.com).
 [2018-01-22 05:46 UTC] zhang_xiaobao at venustech dot com dot cn 
I hava already sent the process dump information to you by email(1486805345@qq.com),please check it.
 [2018-01-22 11:57 UTC] ab@php.net
-Status: Open +Status: Feedback
 [2018-01-22 11:57 UTC] ab@php.net 
Thanks for sending the crash dump. Unfortunately i could only see a few stack frames, because the libhttpd.dll is missing the debug symbols and they're not provided by XAMPP, too. Eg.

>	libhttpd.dll!_ap_run_generate_log_id@12() + 7350 bytes	Unknown	No symbols loaded.
 	[Frames below may be incorrect and/or missing, no symbols loaded for libhttpd.dll]		Annotated Frame
 	libhttpd.dll!_ap_signal_parent@4() + 7799 bytes	Unknown	No symbols loaded.
 	libhttpd.dll!_ap_run_mpm@12() + 43 bytes	Unknown	No symbols loaded.
 	httpd.exe!OPENSSL_Applink() + 2950 bytes	Unknown	No symbols loaded.

Please also note, that the lack of debug symbols is a usual thing, if no official builds are used.

From the code flow, the command execution would normally block until the command has finished. Every thread has it's own structures, that would be destroyed separately.

However one guess that i have is about OpenSSL. The report is about 7.0.27 which we officially link with OpenSSL 1.0.2, but from the dump i see that the Apache distribution is linked with OpenSSL 1.1.0. It is likely to cause issues in completely unrelated parts. So please check and ensure, that both PHP and Apache are linked with the same OpenSSL version. It were preferable to use teh official PHP builds and httpd from apachelounge.com. Please also ensule that the runtime is same, too.

Another point is - PHP below 7.2 has issues with the thread safety, which was fixed in 7.2 and won't be backported. It might make sense, now that 7.2 is out and you use PHP as Apache module, to upgrade it. 

On my side, i've also tested your snippet with PHP as Apache module under quite some stress scenarios like "ab -c 4", but still couldn't able to get on the crash :(

Thanks.
 [2018-01-23 02:42 UTC] zhang_xiaobao at venustech dot com dot cn
-Status: Feedback +Status: Open
 [2018-01-23 02:42 UTC] zhang_xiaobao at venustech dot com dot cn 
Thank you for your suggestion,I'll retest this vulnerability later on your advice and send you a document on the details of the vulnerability.
 [2018-07-07 16:04 UTC] ab@php.net 
Any news on this?

Thanks.
 [2018-07-07 16:04 UTC] ab@php.net
-Status: Open +Status: Feedback
 [2018-07-15 04:22 UTC] php-bugs at lists dot php dot net 
No feedback was provided. The bug is being suspended because
we assume that you are no longer experiencing the problem.
If this is not the case and you are able to provide the
information that was requested earlier, please do so and
change the status of the bug back to "Re-Opened". Thank you.
 [2018-12-14 21:04 UTC] david dot soft at yahoo dot com 
I am still having this issue on both php.exe and php-cgi.exe on Apache.

Sample code:
$test = new COM('WScript.Shell');

This causes PHP 7.2.9 x64 ZTS to crash.

Any ideas?
 [2018-12-14 21:07 UTC] requinix@php.net 
Same question for you: please provide a backtrace or crash dump.
 
PHP Copyright © 2001-2024 The PHP Group
All rights reserved. 		Last updated: Sat Dec 21 17:01:58 2024 UTC