Having been doing OSCP training for the last month, so I didn’t bother to write vulnhub walkthroughs anymore. Anyway, after OSCP exam I will probably switch to hackthebox, so might be no more vulnhub walkthroughs unless I found any box interesting enough for me to write a walkthrough. =(

Back the the topic, this is just something I found quite strange when making my own box during internship and I think it is worthy to write down. Briefly describing:

when using move_uploaded_file($src,$dest), if $dest already exists, what is the expected behaviour of php? I have asked some of my friends, they all said that the$dest will be overwritten, it is my original thoughts also, until it overwrote my upload functional file with owner as root and permission as 644.

I was writing a vulnerable upload functional file named upload.php, due to some reason, the uploaded files need to be in the same directory of upload.php, scared of upload.php being overwritten, I chown root:root upload.php and chmod 644 upload.php, but still, my upload.php can be overwritten, and I have to rewrite my upload function as I didn’t backup ><

since my apache server was running by the default as www-data user, not even in the root group, it should not be able to overwrite my upload.php, I started to wonder the behaviour of move_uploaded_file(), so I did the following experiment.

1. chown root:root upload.php and chmod 000 upload.php -> still can be overwritten.
2. chown root:root . , chmod 777 . upload.php and chmod a+t . -> upload.php cannot be overwritten anymore.

with sticky bit set in the web directory, all the files within the directory can only be deleted by root and its owner. So move_uploaded_file() is actually trying to delete my existing file first, then create a new one? That also align with the output of ls -al upload.php as the overwritten upload.php is now www-data : www-data

I decided to go to the source code level to figure out the underlying behaviour of move_uploaded_file()

from line 5816 to 5866 in /ext/standard/basic_functions.c

SG macro is to retrieve the attributes from the global sapi_globals_struct, which is defined in line 141 to 145 in /main/SAPI.h, so this is just to determine if the file is uploaded this time. if not, return false.

this is to pass the parameters from users, if any of the parameters is not convertible or number of parameters does not align, it will report error. Basically it is just an intermediate function to pass parameters.

to check the hash of the uploaded file to see if the path is within rfc1867_uploaded_files, if not, return false. This is to make sure that move_uploaded_file only does what its name suggests.

open_basedir check, nothing much to say

here comes the most important part, if will first call VCWD_RENAME(path, new_path) if not successful, then call php_copy_file_ex(path, new_path, STREAM_DISABLE_OPEN_BASEDIR TSRMLS_CC) == SUCCESS, as the function name suggests, it will try to rename $src to$dest first, if not successful, then try to copy $src to$dest, so need to trace to VCWD_RENAME().

from line 297 to 301 in /TSRM/tsrm_virtual_cwd.h

it might be using the underlying *nix rename function?