PHP File Upload Security Hole - Still No Fix?

WARNING: Sarcasm and useful content both feature below. Kudos to readers who manage to extract the one from the other. I've just been reading in BUGTRAQ about the PHP File Upload security hole. Rasmus' 'fix' was as excellent as can be expected of him. However, I am somewhat mystified as to in what way Zeev's 'fix' is in any way a fix for the problem. Just like Rasmus, he appears to have completely misunderstood what the problem is, and applied a fix that bears no relevance to it whatsoever. Zeev's patch only affects the file 'rfc1867.c'. Why? This file is not where the problem is. There is no change that can be made to this file to fix it. The code in this file is only called if the browser makes a POST request of type multipart/form-data. So, uh, the evil hacker doesn't do that. They use a normal POST or a GET request instead. Or, they use a multipart/form-data request *but don't send a file*! Gah! What deviousness! Despite what Rasmus said on BUGTRAQ, the original poster was quite correct in saying that this is a problem caused by register_globals. The original poster simply underestimated how broken PHP is. Even if you do not use 'register_globals', there is still no way to tell the difference between a genuine PHP-set filename variable, and an evil hacker-set one. The problem is inherently unsolvable without changes to the file upload procedure in PHP, because PHP simply does not know which variables the script is expecting to contain information about uploaded files. I would suggest that the easiest fix is to add a new global array, HTTP_POST_FILES or somesuch, which contains information about files PHP has received, and which *cannot be set any other way*. I would also suggest that you deprecate the utterly broken 'register_globals', and magic_quotes features, and try and remove them completely in a later version of PHP. They are both recipes for certain disaster. The CGI variables should be accessed via a function. If you make its name short (I use 'F' for 'form'), it requires little extra effort from the script programmer, in return for making it possible to write secure scripts. I finally suggest that you just give up on the 'safe_mode' feature. The PHP interpreter is nowhere near well-written enough for this feature to be of any use at all. I await with interest, but little hope, the PHP team's third attempt at an intelligent BUGTRAQ posting. Yours sincerely, Jon