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

Rasmus Lerdorf <rasmus@php.net> wrote: > Your overall tone makes you easy to ignore. I wasn't sarcastic last time. Well, until the fifth time I'd explained the same point repeatedly and you'd still failed to get a clue. > > 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. Well, that's useful, so long as all the evil hackers in the world are completely brain-dead. I realise this isn't *far* from the truth, but it's not quite true I'm afraid. > It is mentioned briefly in the file_upload chapter Mentioning != documenting. > and if you check CVS you will see that it has been there for a long time. So, it's not only undocumented, it's been that way for a long time! Well, that's much better then. > > 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. The only way to fix it is to ignore the global variables and use HTTP_POST_FILES. It doesn't matter how many times you patch PHP, you are either going to have to change the way file uploads work, or use HTTP_POST_FILES. > > 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. That only helps where you are expecting the variable to be empty. It doesn't help prevent programmer confusion as to which variables are Bad and which are Good. Look, really, I think the only way to access CGI variables should be through a function such as GET_EVIL_UNTRUSTED_CGI_VARIABLE() or somesuch. This would probably be impractical, so I would settle for simply having to call a function or use some other special syntax. Mixing them in with the global variables is just ludicrous. > > 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. That depends on whether people have discovered it independently and are getting burned by it. Yes, you could (justifiably) blame them for using undocumented features, but they will probably still be unhappy at you.