Re: PHP File Upload Security Hole - Still No Fix?

JR>> where the problem is. There is no change that can be made to this file JR>> to fix it. The code in this file is only called if the browser makes JR>> a POST request of type multipart/form-data. So, uh, the evil hacker JR>> doesn't do that. They use a normal POST or a GET request instead. Or, JR>> they use a multipart/form-data request *but don't send a file*! Gah! JR>> What deviousness! Well, we have two problems. The first (and most easy to do) is that you can send a valid file POST and _then_ overwrite some variables with other data. This is what Zeev and Rasmus tried to fix. The second problem is "fake" post - with no file data at all, just variables. For this, there's still no fix known to me, and if such fix apperas, I guess it should change semantics of file upload (most probably, file upload name should not contain any directories at all). JR>> Despite what Rasmus said on BUGTRAQ, the original poster was quite JR>> correct in saying that this is a problem caused by register_globals. No. It was _not_ caused by register_globals. Moreover, in PHP 3 it appears in either mode. In PHP 4, however, it does appear only when register_globals is on, but it doesn't mean it's caused by it (old logic principle - after it doesn't mean because of it). JR>> I would suggest that the easiest fix is to add a new global JR>> array, HTTP_POST_FILES or somesuch, which contains information JR>> about files PHP has received, and which *cannot be set any JR>> other way*. There _is_ such an array. But if you close the other way, this will badly break backwards-compatibility (which might be necessary in this case, if no other solution can be found). JR>> I would also suggest that you deprecate the utterly broken JR>> 'register_globals', and magic_quotes features, and try and remove JR>> them completely in a later version of PHP. They are both recipes Thus breaking PHP scripts of thousands of people. Nice suggestion. If register_globals bothers you so much, why just *you* don't turn it off? JR>> I finally suggest that you just give up on the 'safe_mode' feature. JR>> The PHP interpreter is nowhere near well-written enough for this JR>> feature to be of any use at all. Huh? Repeat again. So you are saying: Because security is not 100% we should rop it altogether? That's a pretty new approach to security, previously unknown to me. And what the hell this has to do with _interpreter_??? Interpreter doesn't know a heck about safe mode, it's entirely different module. JR>> I await with interest, but little hope, the PHP team's third attempt JR>> at an intelligent BUGTRAQ posting. Jon, please calm down and relax. You don't really need to insult all PHP developers just because there's some bug in PHP. I have yet to see any _single_ product that had no bugs or mis-features. Please calm down and get real. Insults will take us nowhere. -- Stanislav Malyshev stas@zend.com http://www.zend.com/ +972-3-6139665 ext.106