Bug #68535 [Fbk->Opn]: Uploaded files are not deleted because of missing impersonation
| From: | lf at evasys dot de | Date: | Tue, 02 Dec 2014 13:05:14 +0000 |
| Subject: | Bug #68535 [Fbk->Opn]: Uploaded files are not deleted because of missing impersonation | ||
| References: | 1 | Groups: | php.bugs |
| Request: | Send a blank email to php-bugs+get-188887@lists.php.net to get a copy of this message | ||
Edit report at https://bugs.php.net/bug.php?id=68535&edit=1
ID: 68535
User updated by: lf at evasys dot de
Reported by: lf at evasys dot de
Summary: Uploaded files are not deleted because of missing
impersonation
-Status: Feedback
+Status: Open
Type: Bug
Package: IIS related
Operating System: Windows Server 2012
PHP Version: 5.5.19
Block user comment: N
Private report: N
New Comment:
I added a screenshot with some marks of my procmon log:
https://www.dropbox.com/s/wh4u4d61rxxj4jf/procmon.png?dl=0
Please see the explaination of the log:
Block 1: This is the file upload and the origination of the upload temp file. As you can see, every
action is done with impersonation od IUSR.
Block 2: This is where the PHP script that was targeted by the HTML form is loaded. Also done with
impersonation.
Block 3: This is the result of a test my script does:
**NOTE: I removed my log functions from the script.
// IUSR has "Modify" rights on this folder
$sFolder = "IUSR/";
$sTestFile = $sFolder."test.txt";
// Create test file
$hFile = fopen($sTestFile, "w+");
fwrite($hFile, "test");
fclose($hFile);
// Check if test file was created
file_exists($sTestFile);
// Delete test file
unlink($sTestFile);
// Check if test file was deleted
file_exists($sTestFile);
Also every action done with impersonation.
Block 4: The same test but in another folder where I set IIS_IUSRS with "Modify" rights:
// IIS_IUSRS group has "Modify" rights on this folder
$sFolder = "IIS_IUSRS/";
...like above...
This proves, that my script can normally not write with IIS_IUSRS credentials. Also every action
done with impersonation.
Block 5: The same test, but now in upload_tmp_dir:
// IUSR has "Modify" rights on this folder
$sFolder = ini_get('upload_tmp_dir') ? ini_get('upload_tmp_dir') :
sys_get_temp_dir();
...like above...
This test proves, that my configuration is valid for the upload_tmp_dir. Also every action done with
impersonation.
Block 6: The request ended, the uploaded file was not touched. In this case PHP will delete the
file. But the access is denied and you can see that the impersonation is missing!
procmon can be downloaded here:
http://technet.microsoft.com/en-us/sysinternals/bb896645.aspx
I also proved the log from progmon as native PML (procmon file) and CSV here:
https://www.dropbox.com/sh/eyrxqjqkyqncqdk/AADNOnnfDZeUbW1k950LxryVa?dl=0
Previous Comments:
------------------------------------------------------------------------
[2014-12-02 09:12:59] ab@php.net
How exactly do you see it's missing?
Thanks.
------------------------------------------------------------------------
[2014-12-02 09:08:12] lf at evasys dot de
Status
------------------------------------------------------------------------
[2014-12-01 23:44:28] lf at evasys dot de
IUSR has MODIFY rights to this folder. This folder is also used for session files which can be/are
deleted by GC. The upload tmp files (like any other file created in our PHP/IIS environments) were
originated by IUSR, so it makes so sense to me, why IUSR shouldn't be able to remove especially
this upload tmp files but any other file originated by IUSR.
When I create and then delete a file in the same directory by a simple test script it is also
working.
There is something absolutely going wrong, when PHP tries to delete the temp files of uploads on IIS
webserver. At least I can see in procmon that the impersonation is missing on this delete action.
------------------------------------------------------------------------
[2014-12-01 23:14:54] requinix@php.net
Sounds like a configuration issue with your temp directory, not with PHP itself.
What's the state of the permissions? Temp folders typically get CREATOR OWNER with (nearly)
full rights, or else the IUSR needs them. And remember that there are separate permissions for
creating, modifying, and deleting files.
------------------------------------------------------------------------
[2014-12-01 23:00:32] lf at evasys dot de
Description:
------------
When uploading a file by a HTML form to a PHP script, the uploaded file will remain in
upload_tmp_dir, even when the request ended (and this file was not removed explicitly by the PHP
code).
Test script:
---------------
Any file upload from a multipart HTML form.
Expected result:
----------------
Unused, not moved or not deleted temp files of a file upload are normally deleted by PHP when the
request ended. We can reproduce this on Apache environments. This is also the behavior php.net
describes for file uploads: "The file will be deleted from the temporary directory at the end
of the request if it has not been moved away or renamed.", see: http://php.net/manual/en/features.file-upload.post-method.php
We can also see in procmon that php.cgi.exe tries to delete the temp file.
Actual result:
--------------
The file is created in upload_tmp_dir. In our case with the IUSR account since we use
"Anonymous Authentication" in IIS. The file is not touched by the PHP code. The request
ends. PHP tries to delete the temporary file, but the access is denied.
We analyzed this with procmon. What you can see there is, that php-cgi.exe process seems not
impersonate on the delete request like on move_uploaded_file() or any other filesystem access.
Workaround: If we add MODIFY rights for IIS_IUSRS group on uploaded_tmp_dir the file will be deleted
after the request ended as expected.
Environment: PHP 5.3.x/5.4.x via FCGI on IIS 7.x
Reproduced on WS2012, WS2008 R2.
This may also be a security releated issue, because when PHP does not delete temp files created by
uploads the server is vulnerable by a possible DoS attack.
Maybe related to https://bugs.php.net/bug.php?id=54951
------------------------------------------------------------------------
--
Edit this bug report at https://bugs.php.net/bug.php?id=68535&edit=1