Re: File Upload Security fix

RL>> We probably need a way to mark a variable in the global symbol RL>> table as non-overwritable during GPC handling. Note that this RL>> has nothing to do with whether register_globals is on or off. RL>> This file upload security vulnerability is due to a POST var RL>> overwriting another POST var in whatever context it is in. Maybe we just need to change semantics of file upload? Because "non-overwritable" variable still doesn't fix a problem of fake file upload (once you guess size, you can have any file, and some files, like cryptographic keys, even have standard sizes!) Maybe upload variable should have some array structure that's not achievable by plain variables (like HTTP_UPLOAD_FILES - or how it is called - has)? Or we should have some "special" variable that isn't achievable from upload? Both solutions aren't good because they require changing of most scripts. The real solution would be giving in file path only temporary filename, and using some "strict" function that would derive full path from it. Like: if($uploaded_file != "none") { $f = fopen(uploaded_filename($uploaded_file),"r"); } uploaded_filename will block all ".." tricks and will check we have no pathes there, after which it will prepend upload temporary dir to it. We still have possibility to symlink tricks and races there, but this requires local shell access and write access to upload temp dir, which is problematic anyway. RL>> I hacked in a fix right now that makes sure that if your file upload field RL>> name is 'abc' then you can't set any variables in the same form that RL>> begin with 'apc'. That's a bad fix. If a have form upload variable named "myfile", why I can't have checkbox named "myfile_was_uploaded"? And what it's going to do, just swallow that variable silently and make me pull my hair out trying to figure where did that checkbox go? -- Stanislav Malyshev stas@zend.com http://www.zend.com/ +972-3-6139665 ext.106