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

> 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. What the heck is that supposed to mean? It was a quick fix written in a couple of minutes, labelled as such and very likely to be revised as I said at the time. It was meant to get the ball rolling on fixing this which it has. > 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. I did not misunderstand the problem. There are two aspects to the problem. One where you have a file upload form and overwrite variables from the file upload form with your own later on in the form. The fixes to PHP addressed that aspect. The second aspect to the problem is when you remove the file upload form completely and send that to a script containing a file upload receive script. To fix this we require a semantic change to the way file uploads are handled. Namely a decoupling of the temp filename and the temp file path. > 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*. Which PHP has had for a long time. > 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. We need to educate users a bit better on security issues, but with or without register_globals you can never trust user input. register_globals is not the real problem and removing it will not magically solve anything. > 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. safe-mode is a stop-gap until this can be addressed where it needs to addressed which is in the web server itself. Apache-2.0 gives us per-virtualhost user/group settings. -Rasmus