Last modified: 2013-03-25 14:06:22 UTC
[Just a side note, this is the second time I've typed this up. The first time I entered all of this in and Commit'd it, MediaZilla had an issue with my submission and told me to press Back on my Browser (FireFox). I did so, and was prompted regarding the sending of POST DATA, and etc. I clicked Okay, and I was presented with this form again, but instead of all the text I had entered, each field was reset to its default value: blank. Wonderful] I've managed to isolate 3 bugs in regards to uploading images on a system in which open_basedir for vhosts is in effect. /include/ 638 $data = @getimagesize( $tmpfile ); 682 $file = fopen( $filename, 'rb' ); 716 $file = fopen( $filename, 'rb' ); Line 638 was the most difficult to locate, since error information is being suppressed by the @ operator. I could write up a patch with some code for this, but I have not yet had the time to examen MediaWiki's code base. I did however manage to bypass these problems by simply commenting the blocks of code that they involve, but this is not a solution. Perhaps the best idea would be to use the move_uploaded_file() function to relocate the file to a MediaWiki temporary directory that exists within the open_basedir path. After that, the verification procedures will work without trouble.
I forgot to specify the file that those lines exist in. The file is 'includes/SpecialUpload.php'.
I just patched my copy of MediaWiki with a fix for this issue. In includes/SpecialUpload.php: @@ -78,6 +78,13 @@ *Check for a newly uploaded file. */ $this->mUploadTempName = $request->getFileTempName( 'wpUploadFile' ); + { /* Move uploaded file to temp folder to bypass open_basedir restrictions */ + global $wgTmpDirectory; + $safeFilePath = $wgTmpDirectory . '/' . basename($this->mUploadTempName); + if (move_uploaded_file($this->mUploadTempName, $safeFilePath)) { + $this->mUploadTempName = $safeFilePath; + } + } $this->mUploadSize = $request->getFileSize( 'wpUploadFile' ); $this->mOname = $request->getFileName( 'wpUploadFile' ); $this->mSessionKey = false; and change existing uses of move_uploaded_file to rename: @@ -336,7 +343,7 @@ } } else { wfSuppressWarnings(); - $success = move_uploaded_file( $tempName, $this->mSavedFile ); + $success = rename( $tempName, $this->mSavedFile ); // was move_uploaded_file wfRestoreWarnings(); if( ! $success ) { @@ -367,7 +374,7 @@ $archive = wfImageArchiveDir( $saveName, 'temp' ); $stash = $archive . '/' . gmdate( "YmdHis" ) . '!' . $saveName; - if ( !move_uploaded_file( $tempName, $stash ) ) { + if ( !rename( $tempName, $stash ) ) { // was move_uploaded_file $wgOut->fileCopyError( $tempName, $stash ); return false; } This moves the uploaded file to $wgTmpDirectory before performing the validity tests. You'll need to be sure that $wgTmpDirectory is set to a valid writable directory.
IIUC this allows injection of unvalidated files into the web root.
True, it could place an unvalidated file into the web root if $wgTmpDirectory is located within the web root, which it need not be, but is by default. At the least, code should be added to delete the uploaded file if validity checks fail or if any other error prevents the final move into the final location. This will also avoid relying on some external mechanism to clear out the temp folder and could prevent disc allocation problems on servers with space restrictions.
(In reply to comment #2) > In includes/SpecialUpload.php: According to the last change in June 2008 at https://gerrit.wikimedia.org/r/gitweb?p=mediawiki/core.git;a=history;f=includes/SpecialUpload.php;hb=HEAD this file was moved to includes/specials/SpecialUpload.php Looking at the current codebase at https://gerrit.wikimedia.org/r/gitweb?p=mediawiki/core.git;a=history;f=includes/specials/SpecialUpload.php;hb=HEAD there is no mention of a move_uploaded_file function anymore that you had trouble with in MediaWiki 1.4. Hence this bug report is very likely obsolete - at least the workarounds mentioned here are.
No feedback, so I'm closing this as obsolete. Please reopen if it's still a problem in a recent version.
