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

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