Several months ago, Robin changed the allow_url_fopen directive in php.ini to Off for security reasons. I had an email correspondence and understand the reasons. However, this setting breaks many www applications for php in portage. After reading the exploits, many of them are caused from using /tmp as the upload and session directory. This directory is usually 0777 root:root. On my production server, I use /var/tmp/php/ apache:apache 0755 as my tmp dir for both upload_tmp_dir and session.save_path without issues. I think it resolves the need to turn allow_url_fopen to Off and restores this to the default mod_php setting. Wendall Reproducible: Always Steps to Reproduce: 1. 2. 3.
Using a private directory for upload/session saving is completely unrelated to allow_url_fopen. The most directly dangerous code blocked by allow_url_open being off is this: include($_GET['somevar']); as then an evil user can just pass in the web address of raw PHP code and have it executed. There are lots of other attacks that do NOT need to write any files to abuse allow_url_fopen. The fact that most existing PHP exploits do write files is entirely due to their goals in the attack. One of the latest nasty ones uses PHP to scan your system for some directory where it DOES have write access, and then puts a .c file there, and executes gcc and the new binary to get beyond PHP. I've seen very few webapps broken by the allow_url_fopen setting. For the very few that did have a legimate need for it, and secure code so it wasn't exploited, you can turn on allow_url_fopen using your .htaccess or other per-vhost/directory settings in your apache config. P.S. Your /tmp should be 1777, not 0777. I am considering moving PHP's temporary directories to be under /var/tmp/php/*, but I haven't seen many convincing arguments yet, beyond having them as mode 700 each.
I'm glad to see that you are considering moving the temp dir. I also noted that I should change my /tmp dir to 0700. (My /tmp is 1777 btw, just a typo.) I do agree that a badly coded php app could allow some nasty code to be implemented via include(). I will include instructions for this Gentoo only distro anomaly. This function is required for any Semantic Web related project. Since you need to be able to read content in from other sites. So I think there are alot more projects effected than what you might think. For phpWebSite currently, there is only one module effected, the news reader. However, as soon as several other aspects of the Semantic Web are coded for, there will be others. Every single cms and news reader written in php needs this function. There are several of these projects in cvs currently. I still think it should be On by default. Maybe an alternative "hardened" php.ini for the hardened Gentoo project team to look after. After all, if I can use include() in submitted text, why not just upload my entire script? Would be the same exploit. Especially if input values aren't filtered. I doubt if any app was this unstable/insecure it would make it into the stable branch. At least I would hope. Wendall
phpBB recently had an exploit that directly executed a bunch of code that it was sent via POST request. And the exploit was actively used in the wild - I lost a box to it, as the exploit was abused less than 12 hours after the initial announcement: I hadn't even woken up yet! Gentoo is not the only distro that uses allow_url_fopen = Off. FreeBSD and OpenBSD definetly use it by default as well. We started using it as Gentoo was being deployed to hosting setups, and clueless users were then uploading scripts very similar to the one I pointed out before, which were then exploited by third parties. For a hardened PHP, see http://www.hardened-php.net/ (we support it in PHP4). There was also a project I saw at a PHP conference, to enable/disable single PHP functions at runtime by configuration, but I don't know what happened to it. As I noted, the best route is to turn allow_url_open back on in a per-directory way. I'll have a chat with the apache folk about doing that type of thing after they have integrated the big upcoming apache changes.
