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

I fully agree that using register_globals is a bad idea, and a bad concept. This is one of the reasons i made track_vars on by default for PHP 4.0, and personally encourage people to use these arrays, and have register_globals turned off. Zeev On Tue, 5 Sep 2000, Jon Ribbens wrote: > Stanislav Malyshev <stas@zend.com> wrote: > > Well, we have two problems. The first (and most easy to do) is that you > > can send a valid file POST and _then_ overwrite some variables with other > > data. This is what Zeev and Rasmus tried to fix. > > I would dispute that this is easier. The other method is simply to type > 'http://blah/blah.php?filename=/etc/passwd'. This > method requires copying > the HTML somewhere, sticking in a BASE HREF and editing the content. > > > JR>> Despite what Rasmus said on BUGTRAQ, the original poster was quite > > JR>> correct in saying that this is a problem caused by register_globals. > > > > No. It was _not_ caused by register_globals. > > It was caused by the register_globals *ethos* that it is fine to mix trusted > and untrusted data with no way of telling which is which. > > > JR>> I would suggest that the easiest fix is to add a new global > > JR>> array, HTTP_POST_FILES or somesuch, which contains information > > JR>> about files PHP has received, and which *cannot be set any > > JR>> other way*. > > > > There _is_ such an array. > > There is? It is not documented in /manual/language.variables.predefined.php > or /manual/features.file-upload.php. Where can I find information on this? > > > But if you close the other way, this will badly break > > backwards-compatibility (which might be necessary in this case, if > > no other solution can be found). > > I didn't say close the other way. I said make a way so that people can > change their scripts to be secure. At the moment, there is no way to > write code to safely receive a generic file. > > > JR>> I would also suggest that you deprecate the utterly broken > > JR>> 'register_globals', and magic_quotes features, and try and remove > > JR>> them completely in a later version of PHP. They are both recipes > > > > Thus breaking PHP scripts of thousands of people. Nice suggestion. > > Yes. That's why I said 'deprecate' it not 'remove' it. Make people > undestand > that it was a mistake, and will be removed at some point in the future. > Then you can turn it off by default on a later version. > > > If register_globals bothers you so much, why just *you* don't turn it off? > > That's fine for me, but I'm having this strange altruistic fit of trying > to help other people. > > > JR>> I finally suggest that you just give up on the 'safe_mode' feature. > > JR>> The PHP interpreter is nowhere near well-written enough for this > > JR>> feature to be of any use at all. > > > > Huh? Repeat again. So you are saying: > > Because security is not 100% we should rop it altogether? That's a pretty > > new approach to security, previously unknown to me. > > No, I'm saying "because security is only about 10%, don't give people a false > sense of security by pretending it works". > > > And what the hell this has to do with _interpreter_??? Interpreter doesn't > > know a heck about safe mode, it's entirely different module. > > Whatever. The code you get in php-4.0.2.tar.gz. What I mean is, the > code which runs PHP scripts is not secure in the face of malicious > scripts. Normally this doesn't matter, because the script author is > trusted anyway. But safe_mode tries to allow you to have untrusted > script authors, and I don't think this is a good idea. > > > Jon, please calm down and relax. You don't really need to insult all PHP > > developers just because there's some bug in PHP. > > I've tried doing it without the insults before, and just ran up against > the brick wall of Rasmus' complete cluelessness. I figure if I'm going to > waste my time trying to help, I might as well have some fun doing it. > > Anyway, after the public display of utter ineptness in the form of the > BUGTRAQ postings to date, you lot don't deserve me being nice to you. > > > I have yet to see any _single_ product that had no bugs or mis-features. > > No, but usually the developers of the products can spot a bug when they > see one. > > > Please calm down and get real. Insults will take us nowhere. > > Indeed. As promised in my previous post, kudos to you for reading the > constructive parts of my mail. > > Cheers > > > Jon > > -- Zeev Suraski <zeev@zend.com> http://www.zend.com/