PHP Configuration Change, allow_url_fopen Disabled

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.

In reply to:

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

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?

jason

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

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.

> Even sillier would be the script using that function

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

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

jason

About three of my own.

And what do they do?

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.

Open remote files using fopen().

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.

> If there is a work around, that would be great.

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...

> Are they big deals, not really as its just my personal site.

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

In reply to:
what script uses that if you don't mind saying? I've actually never seen it in use anywhere, just curious

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

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

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

> He in fact supported that it should be disabled for security reasons.

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.

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.

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

In reply to:
And how does that compromise /server/ security?

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.

In reply to:
Particularly since new protestion doesn't stop any DH user launching the very same remote malicious scripts.

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.

>> And how does that compromise /server/ security?
> Because...

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.

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.

> It just makes life a bit less stressful for the user.

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

> I personally like this change.

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.

> It's kinda like service pack 2 for WinXP

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

In reply to:
It's a cut-back of all users' service for a benefit to only those with dodgy code.

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.

In reply to:
... except it isn't: MS gives you the option of staying with SP1.

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.

> 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.

I don't recall OS hackability being part of the DH sevice offering! ;)

> A hack that worked perfectly fine a year ago no longer does.

PHP allow_url_fopen is not a hack. It is a defined feature of the language, provided by DH, and reasonably relied upon by users.

> User using dodgy code shouldn't be using dodgy code
> because it can cause ... the server to be hacked

Well, now we're getting somewhere. What are these server hacks barred by allow_url_fopen OFF? Of which DH "have been spending an increasing amount of time handling issues resulting from"?

Since it seems there can be no such hack that isn't available to a DH user regardless, it would be nice to know, that's all.

In reply to:
I don't recall OS hackability being part of the DH sevice offering! ;)

They offered it about a year ago for like half an hour or so. They pulled it pretty quick though ;)

In reply to:
PHP allow_url_fopen is not a hack. It is a defined feature of the language, provided by DH, and reasonably relied upon by users.

Like register_globals? Dang those PHP people, going and disabling a vital and defined feature of the language by default. Up to no good they are! I swears!

In reply to:
Since it seems there can be no such hack that isn't available to a DH user regardless, it would be nice to know, that's all.

If you're running PHP as an Apache module, maybe them hacks0rz can run their exploit as the user Apache runs under and compromise the http daemon? That ought to affect every site on the server.

On the topic of legitimate users exploiting the service ... Dreamhost has (hopefully accurate) contact information for the users with legitimate accounts. Can't say the same for anonymous users.

One Sploit to rule them all, one Sploit to find them,
One Sploit to bring them all and in the darkness bind them.

Chris, are you a script kiddy wannabee? You seem too interested in understanding how, and why than realizing the bigger picture. I have read your posts...and now thinking you are a major Troll, bumping your posts to make you a bigger troll.

Even I, just a lowly designer, understands...so why can't you...or do you just like to argue for the sake of arguing...

like was said two days ago..quit feeding the Troll...so I will not answer your posts anymore..or any posts that you post to.

Sorry to see your fixation on DRAMA

> They offered it about a year ago for like half an hour or so.

;) "OS hackability" on the the service features list? I must have missed that! ;)

>> PHP allow_url_fopen is not a hack. It is a defined feature of the
>> language, provided by DH, and reasonably relied upon by users.

> Like register_globals?

Well yes actually, going by the fact that register_globals is ON. Which makes me wonder of the fopen() vuln that is hassling DH isn't the alien global include() argument trick.

>> Since it seems there can be no such hack that isn't available
>> to a DH user regardless, it would be nice to know, that's all.

> If you're running PHP as an Apache module, maybe them
> hacks0rz can run their exploit as the user Apache runs
> under and compromise the http daemon? That ought to
> affect every site on the server.

Closing a picket fence gate like allow_url_fopen is hardly an appropriate defence to that.

> Chris, are you a script kiddy wannabee?

No. I'm a developer with an honours degree in Computer Science and 25 years experience in software design and programming.

> You seem too interested in understanding how, and why than realizing the bigger picture.

Sorry I gave the wrong impression, because it is precisely the bigger picture I am interested in. The how and why are the little pieces that make it up.

In particular I'm trying to get an understanding of what DH server security there is. I'm not interested in the site security of users running insecure code... except when I see an announcement that suggests /server/ security is at risk from same.

Having said which, now I see today's "Revised information regarding PHP's allow_url_fopen option" which unlike the original announcement does not mention server security, now saying this is a user app/site security issue:

This change will significantly improve the security
of PHP-based applications running on our servers
so we can spend more time giving you more features!

Though quite why the insecurity of some users' apps should be allowed to consume valuable DH time, and reduce the service provision for the sites that /are/ secure remains an utter mystery to me.

In reply to:
> They offered it about a year ago for like half an hour or so.

;) "OS hackability" on the the service features list? I must have missed that! ;)

You must have. It was hugely popular for the half-hour it was there! Such a shame we missed the opportunity back then, alas. I hear someone went to the extreme with this and installed Windows 3.1 on one of their server boxes to act as the web server. I don't know how they managed to pull that one off, but I think DH pulled the plug on that user pretty quick.

In reply to:
> Like register_globals?

Well yes actually, going by the fact that register_globals is ON.

Um, no it isn't. It most certainly is off on PHP I just installed on my box. It defaults to off. Damnable are those PHP people, breaking stuff like that, so's I swears! They shouldn't go around changing something like that; it might break something.

In reply to:
> If you're running PHP as an Apache module, maybe them
> hacks0rz can run their exploit as the user Apache runs
> under and compromise the http daemon? That ought to
> affect every site on the server.

Closing a picket fence gate like allow_url_fopen is hardly an appropriate defence to that.

The appropriate defense to that being... running all PHP as CGI! Confines the damage, but still leaves a potential vector open. Better close it; users will adapt -- this kind of stuff has been pulled before, and by much more influential folks.

> I hear someone went to the extreme with this and installed Windows 3.1

LOL!

>> Well yes actually, going by the fact that register_globals is ON.

> Um, no it isn't.

crack.dreamhost.com phpinfo() disagrees:

Directive | Local Value | Master Value
...
register_globals | On | On

> It defaults to off.

Sure does.

> The appropriate defense to that being... running all PHP as CGI!

Agreed, and that is what DH wisely recommend.

In reply to:
Agreed, and that is what DH wisely recommend.

...but do not mandate :)

In reply to:
crack.dreamhost.com phpinfo() disagrees:

Directive | Local Value | Master Value
...
register_globals | On | On

localhost phpinfo() disagrees:

Directive | Local Value | Master Value
...
register_globals | Off | Off

My MS-DOS 3.02 beats your MS-DOS 4.01!!!

Edited by Iri on 03/20/05 10:17 AM (server time).

> localhost phpinfo() disagrees:

Which DH machine is that?

Any of them. Try it. Log into your box and ping localhost.

You've lost me there Iri. My point is that the DH PHP installation serving my web pages has register_globals ON. See: www.chrisjj.com/tools/phptest/phpinfo.php .

If you're saying the DH PHP serving yours doesn't, could you give us a phpinfo URL?

PHP Configuration Change, allow_url_fopen Disabled