not sure if this was intended behavior (cant find any changelog mention), but after upgrading my stable system to dev-lang/php-5.2.14, the default configs enabled allow_url_fopen for me. in the past, we always defaulted to Off for security reasons. see Bug 57180.
Yeah, you're right, they were dropped in src_install-v1.eblit. To be honest, I don't know why. I emailed hoffie, asking for clarification. I don't see any striking reason why it shouldn't be turned Off by default, so if I don't get a reply from him soon, I'll switch it back off and blog about the change so installs of 5.2.14 (and 5.3.3-r1) that happen now can turn it back off at their own discretion.
I'm late on this, but anyway: Hoffie replied that he doesn't know anymore ;) allow_url_include is off by default, that should cover most scenarios, shouldn't it? To be honest, I'm not up to date on php exploits, so can't cite numbers about allow_url_open misusage. If it's significant, I'll turn it off once again, but with the usual approach of including your attack script thwarted, it's probably easiest to stick with upstream. What do you think?
historically, it has been off for security concerns. people are used to turning it on (across all distros). unless we have a compelling reason to change this behavior, we should stick with the paranoid behavior of off.
I'm the one that made the decision many years ago to ship PHP4 with it disabled. I stand by that decision still, I've seen it block enough simple hack attempts that it's been entirely valid (and I run all my systems with it disabled).
I've changed it back. Thanks.
seems it's fallen by the wayside again. mabi also pointed Matti also pointed out that we should have allow_url_fopen and allow_url_include default to the same value. so for apache2/cgi configs (i.e. where php is going to a web browser), we want these defaulting to off. but for cli configs, we want it defaulting to on.
(In reply to comment #6) > seems it's fallen by the wayside again. mabi also pointed Matti also pointed > out that we should have allow_url_fopen and allow_url_include default to the > same value. > This is incorrect. allow_url_fopen should be enabled while allow_url_include should not be enabled by default. Earlier on allow_url_fopen controlled both simply fetching a remote url as a string, and including a remote string directly into your output, but was later split as the former is a perfectly normal use case, while the latter is simply insane. Disabling allow_url_fopen for safety reasons would be the same as disabling USE="curl" for safety reasons. Or sockets. > so for apache2/cgi configs (i.e. where php is going to a web browser), we want > these defaulting to off. but for cli configs, we want it defaulting to on. To me, it never makes sense to set allow_url_include to on by default. If you absolutely want to include a remote uri in your output, just do an echo file_get_contents($url);
Years ago as the PHP maintainer, I changed the allow_url_fopen default to Off, to block exploits against bad PHP of these forms: 1. Code injection: include($_GET['var']); // blocked by allow_url_include 2. XSS: echo file_get_contents($_GET['var']); 3. Code injection: $fd = fopen($_GET['var'], "r"); eval(fread($fd,2**24)); In all cases, the PHP developer hasn't sanitized the variables properly before passing to include/file_get_contents. I know you can reproduce them with CURL, but having them blocked by default locks out a lot of malware right away. I still strongly recommend that allow_url_fopen is globally disabled, and sysadmins enable it on a per-app/per-vhost basis with .htaccess, when they know the code is safe there.
(In reply to comment #8) > Years ago as the PHP maintainer, I changed the allow_url_fopen default to Off, > to block exploits against bad PHP of these forms: > 1. > Code injection: > include($_GET['var']); // blocked by allow_url_include So this is no longer an issue as it is off by default. > 2. > XSS: > echo file_get_contents($_GET['var']); > 3. > Code injection: > $fd = fopen($_GET['var'], "r"); eval(fread($fd,2**24)); > Well. It is a programming language. Programmers can do all sorts of crazy stuff with it. By that logic, we should also disable mysql (sql injection) and passthu (CL injection). > In all cases, the PHP developer hasn't sanitized the variables properly before > passing to include/file_get_contents. And that is the problem. Generally, allowing developers to access $_GET directly instead of using filter_input() is the problem in all of the above, not allow_url_fopen. > > I know you can reproduce them with CURL, but having them blocked by default > locks out a lot of malware right away. > passthru("wget -g -O - $_GET[var]"); is another fun thing developers do. > I still strongly recommend that allow_url_fopen is globally disabled, and > sysadmins enable it on a per-app/per-vhost basis with .htaccess, when they know > the code is safe there. I am not very strongly against changing upstream default settings where it makes sense, but in this case I do not think it does. It is not really our job to protect hosts against their developers' user land code, nor do I think it is the job of a programming language.
(In reply to comment #9) not really. it's always a matter of tradeoffs. servers disabling url fopen is not uncommon, so programmers/admins are used to enabling it whenever they actually need it. conversely, the number of attacks in practice against that option are not uncommon. so in this case, it makes sense to make that trade off -- a default that isn't disruptive to legitimate users but is disruptive to illegitimate.
I have discussed this with Matti and others and there is a rather large consensus (as in unanimous) to follow upstream. Even debian ships with allow_url_fopen = On.
