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

go to bug id or search bugs for

Bug #78583 Segfault on using RecursiveDirectoryIterator
Submitted: 2019-09-22 05:30 UTC Modified: 2024-01-04 20:25 UTC
Votes:1
Avg. Score:1.0 ± 0.0
Reproduced:0 of 0 (0.0%)
From: tarunkant05 at gmail dot com Assigned:
Status: Verified Package: SPL related
PHP Version: Irrelevant OS: Linux
Private report: No CVE-ID: None
View Developer Edit
Welcome back! If you're the original bug submitter, here's where you can edit the bug or add additional notes.
If you forgot your password, you can retrieve your password here.
Password:
Status:
Package:
Bug Type:
Summary:
From: tarunkant05 at gmail dot com
New email:
PHP Version: OS:

 

 [2019-09-22 05:30 UTC] tarunkant05 at gmail dot com 
Description:
------------
Description: If you block `SplFileInfo` in disable_classes, and use `RecursiveDirectoryIterator` then using the test script it can segfault, as it is performing in File System it is more effective. 
As segfault can lead to RCE using LFI and Race condition, files don't get deleted when files get uploaded during SegFault. 
Here segfault is in File System so it can be much more frequent if the developer blocks the `SplFileInfo`.

This bug is caused by Null Pointer Dereference.

Test script:
---------------
function iterate($me){
	foreach($me as $whole){
		echo "Great";
	}
}

iterate(new RecursiveDirectoryIterator('/'));

Expected result:
----------------
should be blocked by PHP, because of disable_classes

Actual result:
--------------
#0  0x000055555589d50f in spl_filesystem_object_create_type (ht=0x0, source=0x7ffff3a84000, type=0x0, ce=0x555556836900, return_value=0x7ffff3a93060) at /home/vignesh/Documents/exploits/php/php-src-master/ext/spl/spl_directory.c:509
#1  0x000055555589f590 in zim_spl_FilesystemIterator_current (execute_data=0x7ffff3a14120, return_value=0x7ffff3a93060) at /home/vignesh/Documents/exploits/php/php-src-master/ext/spl/spl_directory.c:1103
#2  0x0000555555a4d96a in zend_call_function (fci=0x7fffffffa430, fci_cache=0x7fffffffa410) at /home/vignesh/Documents/exploits/php/php-src-master/Zend/zend_execute_API.c:802
#3  0x0000555555a8ec1e in zend_call_method (object=0x7ffff3a85090, obj_ce=0x55555683ce00, fn_proxy=0x55555683d380, function_name=0x5555561ff519 "current", function_name_len=0x7, retval_ptr=0x7ffff3a93060, param_count=0x0, arg1=0x0, arg2=0x0) at /home/vignesh/Documents/exploits/php/php-src-master/Zend/zend_interfaces.c:103
#4  0x0000555555a8ef3b in zend_user_it_get_current_data (_iter=0x7ffff3a93000) at /home/vignesh/Documents/exploits/php/php-src-master/Zend/zend_interfaces.c:179
#5  0x0000555555afd546 in ZEND_FE_FETCH_R_SPEC_VAR_HANDLER () at /home/vignesh/Documents/exploits/php/php-src-master/Zend/zend_vm_execute.h:20592
#6  0x0000555555b3a346 in execute_ex (ex=0x7ffff3a14020) at /home/vignesh/Documents/exploits/php/php-src-master/Zend/zend_vm_execute.h:55000
#7  0x0000555555b3c276 in zend_execute (op_array=0x7ffff3a81300, return_value=0x0) at /home/vignesh/Documents/exploits/php/php-src-master/Zend/zend_vm_execute.h:56926
#8  0x0000555555a64a34 in zend_execute_scripts (type=0x8, retval=0x0, file_count=0x3) at /home/vignesh/Documents/exploits/php/php-src-master/Zend/zend.c:1631
#9  0x00005555559ca4ea in php_execute_script (primary_file=0x7fffffffcd70) at /home/vignesh/Documents/exploits/php/php-src-master/main/main.c:2633
#10 0x0000555555b3ef0e in do_cli (argc=0x4, argv=0x55555678afb0) at /home/vignesh/Documents/exploits/php/php-src-master/sapi/cli/php_cli.c:991
#11 0x0000555555b40085 in main (argc=0x4, argv=0x55555678afb0) at /home/vignesh/Documents/exploits/php/php-src-master/sapi/cli/php_cli.c:1381

Patches

Pull Requests

History

AllCommentsChangesGit/SVN commitsRelated reports
 [2019-09-22 08:44 UTC] stas@php.net
-Type: Security +Type: Bug
 [2019-09-22 13:06 UTC] duncan3dc@php.net 
I think this is caused by the SPL extension creating different types of objects, and then internally changing them into instances of SplFileInfo:
https://github.com/php/php-src/blob/071ccee7f7fd9a3d3e2555be093f2e5fef40e507/ext/spl/spl_directory.c#L504

So the overridden create_object handler is never called. Perhaps we could expose *display_disabled_class* in a similar way to *display_disabled_function*, so that the SPL extension could check if a class was disabled before attempting to use it
 [2020-04-24 18:49 UTC] alexinbeijing at gmail dot com 
This appears to be a duplicate of Bug #62737.
 [2021-09-06 17:17 UTC] cmb@php.net
-Status: Open +Status: Verified
 [2021-09-06 17:17 UTC] cmb@php.net 
> So the overridden create_object handler is never called. Perhaps
> we could expose *display_disabled_class* in a similar way to
> *display_disabled_function*, so that the SPL extension could check
> if a class was disabled before attempting to use it

I think we should not to call spl_filesystem_object_new_ex()
directly, but use object_init_ex() instead.
 [2024-01-04 20:25 UTC] bukka@php.net
-Package: *Directory/Filesystem functions +Package: SPL related
 
PHP Copyright © 2001-2024 The PHP Group
All rights reserved. 		Last updated: Thu Nov 21 11:01:29 2024 UTC