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

Rasmus Lerdorf <rasmus@php.net> wrote: > > Rasmus' 'fix' was as excellent as can be expected of him. > > What the heck is that supposed to mean? I was just spanking you for ignoring me last time ;-). I don't have a high opinion of you since then. > 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. Yes. Maybe you should have labelled it "here is a patch, which you should ignore because it is won't fix the problem and it will break things". > I did not misunderstand the problem. There are two aspects to the > problem. Yadda yadda yadda. No there aren't. There is exactly one aspect to the problem. The filename turns up in a variable which might not have been set by PHP, but by an evil hacker instead. Fixing the special case of where the evil hacker for some reason tries to upload the file *and* change its name at the same time is completely pointless, since if you fix that they simply will do it another way and ignore the 'fix'. > > 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. No, it hasn't. It is not documented. If it isn't documented, it doesn't have it. If you don't understand why this is, ask and I will explain it to you. And, since PHP *does* already have the solution to the problem ready and waiting in the code, why on earth is anyone talking about patches to the code when all that is needed is a documentation fix? > 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. register_globals is *a* problem. The underlying problem is of course evil users who send bad data. register_globals causes a *new* problem by mixing in this bad data with the trusted script variables, thus making it hard for the programmer to avoid trusting the user input. > safe-mode is a stop-gap until this can be addressed where it needs to > addressed which is in the web server itself. Until you document this, it will be a security hole. Cheers Jon