Re: PHP File Upload Security Hole - Still No Fix?
| From: | Zeev Suraski | Date: | Tue, 05 Sep 2000 15:37:48 +0000 |
| Subject: | Re: PHP File Upload Security Hole - Still No Fix? | ||
| References: | 1 2 3 | Groups: | php.dev |
| Request: | Send a blank email to php-dev+get-32197@lists.php.net to get a copy of this message | ||
I'm not replying to any particular letter to avoid the all too common back-and-forth accusations.
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. If the answer is the former, we'll part as friends. If it's the latter, let's think about what should be done. For the rest of the letter, I'll take the liberty of assuming the answer would be that you're not giving up.
First, I want to understand the source of your resentment towards the source code of PHP.
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. PHP's core has been written with security in mind. I'm not talking about safe mode (which is a usability feature, and not a security feature), but rather, about the programming style and techniques (binary safety to avoid buffer overflows, being aware of race conditions, etc.). Nothing is perfect. And to add another corny slogan - he who doesn't do anything, doesn't go wrong.
Now, as you may have noticed, I was talking about the core of PHP. I'm sure there are bugs lurking in modules for 3rd party libraries, an assumption based on the amount of buglets (that could turn into security holes) when I ported a few modules to PHP 4.0. Unfortunately, I don't see a magical solution for this one, other than encouraging people to code better, with security in mind.
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. 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 (it is turned off in php.ini-optimized, by the way, but I assume not too many people use it yet). We can also hint people that they can easily copy these arrays to shorter names, like $POST, $GET, $COOKIE etc., since it poses no performance penalty. There's no need for your one letter functions, which greatly reduce performance.
Once we finalize our analysis of how things should look, and finish making any additional patches - we'll submit a complete summary.
Finally, and I don't want to start an argument, but you should do something about your tone. You may not like certain things in PHP, you may not like certain people that are behind PHP to one extent or another, but it doesn't mean you have to shout it out at prime time. Civilized conversation does a much better job, almost always. I'm not looking for apologies (in case you felt like giving one); I'm talking about the future.
Zeev
P.S.: It is true that PHP didn't buy its place in the world thanks to technical excellence, there were many flaws in PHP 3.0, which took over the world. It took over mostly thanks to ease of use and functionality. However, PHP 4.0 changes that. It is technically excellent, at least its core is, and it's propagating to the exterior parts, slowly but surely.
--
Zeev Suraski <zeev@zend.com>
http://www.zend.com/