PHP Configuration Change, allow_url_fopen Disabled


#1

Bad news below. How we are supposed to keep apps running on a provider that pulls sections of rug out from under them WITHOUT EVEN ADVANCE NOTICE, goodness only knows.

And since php_info() says:

Directive Local Value Master Value
allow_url_fopen On On

have DH got some way of making disablings hidden from phpinfo()?

Chris

PHP Configuration Change, allow_url_fopen Disabled (Policy Change)

Posted: Mar 16th, 2005 - 11:42:06 AM PST (23 hours 20 mins ago)

PHP provides a feature allowing a programmer to open, include or otherwise use a remote file using a URL rather than a local file path. Unfortunately, that feature is the source of a large number of security holes in PHP web applications running on our servers and we have been spending an increasing amount of time handling issues resulting from those security exploits.
In the interest of overall system security, we have decided to disable this feature as of now. We apologize for any inconvenience this may cause. Please contact our support team if you have any questions.


#2

I understand (and sympathize with) your “rug out” comment but leaving something open that is such an easy target for compromising a server would be silly in my opinion. Even sillier would be the script using that function, that’s just asking for bad fu innit?

[color=#0000CC]jason[/color]


#3

[quote]leaving something open that is such an easy target for compromising a server would be silly

[/quote]

I don’t see DH saying it is an easy target. I tdo see DH saying “we have been spending an increasing amount of time handling issues resulting from those security exploits” and I read that to mean that this cut-back is for reduction of costs.

That’s reduction of DH’s costs. At the expense of increasing the costs of the users that make use of it. Not just in code modification, but in downtime resulting from DHs (baffling) failure to give advance notice.

[quote]Even sillier would be the script using that function

[/quote]

Clearly not, since DH have supported it for years up until now.


#4

what script uses that if you don’t mind saying? I’ve actually never seen it in use anywhere, just curious

[color=#0000CC]jason[/color]


#5

About three of my own.


#6

And what do they do?


MacManX.com
I don’t work here. I’m just your typical support forum volunteer.


#7

The recommended workaround for allow_url_fopen is the curl library. Where I used to have a piece of code which did this:

fopen(“http…”); $output .= fread(); fclose();

I substituted the following:
$ch=curl_init();
curl_setopt($ch, CURLOPT_URL, “http…”);
curl_setopt($ch, CURLOPT_HEADER,0);
curl_setopt($ch, CURLOPT_RETURNTRANSFER, 1);
$output .=curl_exec($ch);
curl_close($ch);

works just fine.


#8

Open remote files using fopen().


#9

I use it in 2 scripts that run on my page.

One of them grabs a quote from the quote of the day website, qotd.com and places it in an sql database on my site.

Another I use in a DVD tracking program. I enter in information, and it goes off to Amazon and grabs some information like the review, etc so I don’t have to enter in a ton of data.

If there is a work around, that would be great. But it is going to stop these two scripts from working. Are they big deals, not really as its just my personal site. but it was somehting that was nice and valuable to me.


#10

[quote]If there is a work around, that would be great.

[/quote]

There are worksaround, including rknobbe’s above (thanks R).

But the problem is not that workarounds like this cost time and reduce code quailty by doubling the size and reduding portability…

[quote]Are they big deals, not really as its just my personal site.

[/quote]

… but on business sites, that there’s downtime inflicted until such workarounds can be implemented.


#11

a quick recursive grep appears to show Gallery using fopen() for an URL as one of its picture-uploading options.


#12

I was told by a developer today that Gallery2 (at beta stage right now) doesn’t need allow_url_fopen to be enabled. He in fact supported that it should be disabled for security reasons. Just to let people know.

www.stoffersphoto.com


#13

[quote]He in fact supported that it should be disabled for security reasons.

[/quote]

I wonder what those reasons are. Clearly allow_url_fopen “On” may open a vuln in just the site having the sloppy scripting, but if he’s supporting DHs assertion that it may open a vuln in /server/ security, then it would really be good to know how.


#14

Because, like a virus or trojan horse, it can allow any remote malicious script to be opened and run without the users knowledge. It’s not a difficult concept to grasp.


MacManX.com
I don’t work here. I’m just your typical support forum volunteer.


#15

And how does that compromise /server/ security? Particularly since new protestion doesn’t stop any DH user launching the very same remote malicious scripts.


#16

Because, like a virus or trojan horse, it can allow any remote malicious script to be opened and run without the users knowledge. It’s not a difficult concept to grasp.

Because a DH user would have to make a change to the code. If it was a malicious script, the DH user would have no clue that a change to the code is required., because he would have no clue that the call even existed in the first place. If he is aware of the call and does make the change (for whatever reason), then DH user would at least have an extra chance to investigate the remotely called script. It’s not a difficult concept to grasp.


MacManX.com
I don’t work here. I’m just your typical support forum volunteer.


#17

Because…

[/quote]

I’ve heard your “Because”, thanks. But it doesn’t asnwer my question: “How”.

'Cos I cannot see How server security can be breached by a malicious script run by one of its users.


#18

The malicious script could possibly exploit a vulnerability in the host OS? Of course, a user with malicious intent could exploit a vulnerability in the host OS just as well, so you really need to secure the host OS from the user anyway.

It just makes life a bit less stressful for the user. Assuming your scripts aren’t breaking, of course. I personally like this change. It’s kinda like service pack 2 for WinXP breaking some programs that were coded sloppy; right security decision, poor decision for compatibility.


#19

[quote]It just makes life a bit less stressful for the user.

[/quote]

As I thought. So this is not about the security of the server, but of the sites of users of dodgy code.

[quote]I personally like this change.

[/quote]

I don’t. It’s a cut-back of all users’ service for a benefit to only those with dodgy code. A hosting provider starting on that slippery slope soon finds it leads to the worst service and worst customers.

[quote]It’s kinda like service pack 2 for WinXP

[/quote]

… except it isn’t: MS gives you the option of staying with SP1.


#20

Applying OS patches is also a cut-back of all users’ service because the poor users can’t hack the OS to get better service. Now how wrong is that? A hack that worked perfectly fine a year ago no longer does. That’s just plain wrong.

Besides, dodgy code should be eradicated. Eradication of dodgy code is good. User using dodgy code shouldn’t be using dodgy code because it can cause problems for my good code residing on the same server as the dodgy code that’s eating up all the server resources or causes the server to be hacked.

Sloppy coding is baaa-aa-aaaad… and far too common.

Wish they didn’t. Come to think of it, wish Microsoft would code better in the first place. Barring that, mandate SP2 and let the bad code die. But that’s just me.