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. Your overall tone makes you easy to ignore. > > 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". It did fix the exact exploit posted. It did not fix variations of it. > 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. It is mentioned briefly in the file_upload chapter and if you check CVS you will see that it has been there for a long time. > 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? Because it can be made with register_globals on as well. > > 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. I wouldn't say it is hard. You just have to initialize your variables. > > 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. Actually, safe-mode wasn't documented at all, so by your own logic safe-mode does not exist and can therefore not be a security hole. -Rasmus