Re: Security Issues

I wrote a thorough response while being disconnected, but it's kind of pointless to send it considering the face to face discussion we had today. The only thing I'd like say here is that in my opinion, the fact form variables are defined as globals (as opposed to being defined just as automatically inside $_GET/$_POST or $_FORM) is hardly what makes PHP what it is. Auto form variable registration is very important and is one of the cornerstones of PHP, but it'd be equally good if it had a different syntax. Other cornerstones that make PHP what it is are the clean and non obscure syntax (I bet Thies doesn't use PHP for his shell scripts because of auto form variable registration...), the easy to use database APIs which come within the binary, and the fact it contains a full set of Web tools built into it. I think that portraying PHP as some weak version of Perl with auto global form variables is not even an understatement, but just plain wrong... Anyway, to be more constructive - Andi had an idea when we were catching a cab earlier today (yesterday). His idea (which I'm just pitching, we haven't thought this through at all yet) is that instead of having register_globals on, or off, we would have it as unset, by default. When unset (i.e., on new installations) - PHP will not run, but instead display information about register_globals, its security implications, examples, and a general recommendation to turn it off if at all possible. We can easily point the user to the location of the php.ini file that he has to edit in order to modify register_globals to be either on or off. Again, I'm just pitching this idea, I'm not entirely sure if it's good or not. Personally, I still lean towards having register_globals off by default for new installations. This will have a very small effect on existing apps (for better and worse), it'd encourage (force) application developers to write portable applications (which is a good thing - apps based on register_globals=on are not portable, since many security-aware people turn it off), and obviously, solve the security issues we've been discussing. If we release it as 4.1.0, it's going to generate enough noise to make people aware of this issue, which is also a good thing. Zeev At 10:30 27/07/2001, Rasmus Lerdorf wrote:

This is an important step, that as I said, I wanted to make for years. I just argue that as protective as you are over register_globals=on, the real flaw is there, and this is the place it should be fixed. Fixing the fact that E_NOTICE is on may also be viable, but in practice: - A huge number of cases where E_NOTICE's will be generated isn't related to security in any way, and people will be kind of pissed by it, and probably turn it back off That's an issue that can be addressed. We perhaps need better granularity on the E_NOTICE. If we distribute a php.ini-recommended, we can, and probably should enable E_NOTICE's by default. It's not the solution to the problem raised in the advisory. The very first and primary example in the advisory would most definitely have been caught by an E_NOTICE, so I don't see how this doesn't address the advisory. For reference the first example in the advisory is: <?php if ($pass = "hello") $auth = 1; ... if ($auth == 1) echo "some important information"; ?> First, the guy who wrote the advisory didn't check his code, because the above could never actually be a problem since he confuses == and = and actually always sets $auth=1, but ignoring that and fixing his code, if you turn on E_NOTICE this script generates: Warning: Undefined variable: pass in foo.php on line 2 Warning: Undefined variable: auth in foo.php on line 5 And the second example is: <?php if (!($fd = fopen("$filename", "r")) echo("Could not open file: $filename<BR>\n"); ?> Again, an obvious bracket mismatch so this example also doesn't run, but running this with E_NOTICE gives: Warning: Undefined variable: filename in foo.php on line 2 Warning: Undefined variable: filename in foo.php on line 3 Same goes for example 3 which is: <?php include($libdir . "/languages.php"); ?> Then he talks about the file upload issues which is a separate problem and one we have addressed. And then he talks about .inc files and suggests that people who just use .php for include files are vulnerable because their scripts could be run out of context. This is a different issue as well.

But that's not the point. The point is that people who don't care about security or coding style (beginners or professionals, doesn't really matter) are less likely to write insecure code, because there's one mistake less that they can make. As long as they stick to the defaults, anyway.

And one language less that these people are able to use.

That's an empty statement, Rasmus... The auto-registered form variables are not any less usable if we change the access method to them slightly. I'd argue it actually makes the code much more readable and newbie-friendly, actually. Why are new users latching onto PHP instead of Perl:CGI? PHP is not an inherently better scripting language. In fact it is probably significantly weaker. People use PHP because they find it easy to understand and easy to learn and because it is targeted to the Web problem. We have a responsibility to help people write more secure scripts, but we also cannot keep adding complexity to the point where we lose what makes PHP what it is. And we need to explore all the options we have here instead of jumping to conclusions. -Rasmus

-- Zeev Suraski <zeev@zend.com> CTO & co-founder, Zend Technologies Ltd. http://www.zend.com/