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

From: Date: Wed, 06 Sep 2000 18:16:17 +0000
Subject: Re: PHP File Upload Security Hole - Still No Fix?
References: 1 2 3 4 5 6  Groups: php.dev 
Request: Send a blank email to php-dev+get-32431@lists.php.net to get a copy of this message
At 12:28 06-09-00, Jon Ribbens wrote:
Zeev Suraski <zeev@zend.com> wrote: There's basically one question you should be asking yourself right now - are you going to whine, or are you going to do something about changing what you think to be wrong. What's the difference? These are policy issues, the only way to change them is to talk about them.
The difference is in the approach. You started off by whining. If that's what you wish to do, I'll appreciate it if you do it off the mailing list. Constructive criticism is something completely different from whining or bashing others.
Personally, there are great deals of code that I don't particularly like (the file upload code happens to be one of them), but most of PHP's core is extremely clean *and* secure nowadays. I must admit most of my experience is with PHP 3. PHP 4 only started working on OpenBSD with the PHP 4.0.2 release the other day. But, the only issue that I have mentioned with the PHP source is that I don't think safe_mode is a good idea. (And yes, I think the source is ugly, but that's somewhat subjective.) (binary safety to avoid buffer overflows, I found this interesting undocumented feature while looking at all this file upload stuff: php_variables.c:202-205 /* FIXME: XXX: not binary safe, discards returned length */ php_url_decode(var, strlen(var)); php_url_decode(val, strlen(val)); php_register_variable(var, val, array_ptr ELS_CC PLS_CC); Sheesh. "Warning: PHP may unexpectedly corrupt your data."
It seems to me more and more that you're not serious - all you seem to do all the time is whine. As for the issue itself - I'm not sure if we're expecting binary data here (I'm pretty sure we're not). Considering the huge userbase and the fact nobody complained so far, it sounds like you're even whining about the wrong things.
As for the actual patch - I have to admit that as it doesn't completely eliminate this exploit family, it's not all that useful. It doesn't do anything at all! It was a complete waste of time. You might as well write a patch to fix the special case where the evil hacker's name is Ian. This is the main cause of my sarcasm in this thread. You're all trying very hard to give the impression that you simply don't know what you're doing.
Trust me, I know exactly what my patch does and what it doesn't do (and I knew that before you pointed it out so wisely). Security wise, it doesn't do much. Functionality wise, it prevents PHP from overwriting variables it's not supposed to overwrite. I'm not one of the people that would tell you 'if you don't like this, get a CVS account and do it yourself', as personally I couldn't care less if you got a CVS account or not. If you hate PHP, or some aspects of PHP so much, don't use it. None of us will cry over this. If you want to improve PHP, stop whining and bashing, and start talking like a grown person. In case you haven't noticed, people are fed up with your approach (which doesn't come to say that what you're getting at isn't good - but your way of doing it sucks).
I've been an advocate of track_vars for years now, and I too think that register_globals is a disaster waiting to happen in some cases. I'm in favour of documenting this and encourage people to turn it off Excellent. Put it in the manual! Make the next release have it turned off by default! For sure, put in really large letters in the release notes what you've done, but new users and new scripts should not continue to be written using register_globals.
Breaking 99.9% of the scripts in the world isn't my idea of fun, and thus it's likely register_globals will remain on by default always. Encouraging people in whatever way possible to turn it off is a good motivation.
There's no need for your one letter functions, There's no *need*, they just help the script author write scripts more easily and quickly, and encourages them to do things the right way. I thought PHP was all for this. (I can't imagine otherwise why you have such a vast number of built-in functions.)
It's simply the wrong way to do a right thing.
which greatly reduce performance. Make them keywords. Use a special '%' syntax. Whatever. What you say here is simply untrue.
I might be funny here, but I kinda trust what I have to say about the subject more than I trust what you have to say about the subject. Using functions to access globals is extremely slow, and thus completely silly (c). Use one letter variables if you wish, just don't use functions.
Finally, and I don't want to start an argument, but you should do something about your tone. You people don't deserve me being nice to you. Be that as it may, this is a sarcasm-free posting. Rejoice.
If that tone is going to continue, this is the last time I'll converse with you. I don't see why this should be the case, but that's your choice. Zeev -- Zeev Suraski <zeev@zend.com> http://www.zend.com/

« previous php.dev (#32431) next »