#23236 [Fbk->Opn]: move_uploaded_file corrupts images

ID: 23236 User updated by: dan at GARBAGE dot highspeedlink dot net Reported By: dan at GARBAGE dot highspeedlink dot net -Status: Feedback +Status: Open Bug Type: Unknown/Other Function Operating System: Linux 2.4.18-14 RedHat 8 PHP Version: 4.3.1 New Comment: My apologies--FollowSymLinks got smashed in the config at some point. See if you can see any obvious problems before I recompile PHP yet again, please? PHPInfo page added at http://admin.highspeedlink.net/PHP/info.php for your edification. Previous Comments: ------------------------------------------------------------------------ [2003-04-17 01:16:22] magnus@php.net Please try using this CVS snapshot: http://snaps.php.net/php4-STABLE-latest.tar.gz For Windows: http://snaps.php.net/win32/php4-win32-STABLE-latest.zip and that link to the source code of the script gives a permission denied error. ------------------------------------------------------------------------ [2003-04-16 02:16:33] dan at GARBAGE dot highspeedlink dot net (remove GARBAGE to reply, or it gets feed into the spamtrap) Can anybody explain what's happening to perfectly good images passing through http://admin.highspeedlink.net/PHP/ for me? The code for the page is available at http://admin.highspeedlink.net/PHP/source.txt for your perusal. I've tested with MSIE 6.0 and Mozilla 1.4a on Windows, so this doesn't seem to be browser-specific. Also, running dos2unix, unix2dos, etc. doesn't seem to help. Considering what suggestions I've seen thus far, I'm thinking this is a bug, possibly related to character encoding, in move_uploaded_file(). Can people test this out and see how deadly it really is? Warning for the squeamish: the linked page allows uploading of arbitrary images up to 100 [decimal] KB in size, and displays the last uploaded image. No promises on what will or won't be there when you look. Just upload only pictures of http://www.google.com/images?q=flowers and such, okay? Feel free to upload arbitrary binary data and access it directly, as well--no filetype restrictions are in place. This is not a localized copy of Apache, and thus #11066 does not apply. (Indeed, my Apache 2.0.43 doesn't even recognize the CharsetRecodeMultipartForm directive.) ------------------------------------------------------------------------ -- Edit this bug report at http://bugs.php.net/?id=23236&edit=1