register_globals again!

I just switched to dreamhost and to my horror learned that register_globals is still enabled. I spent an hour researching what others have done with this and haven't found anything. It seems I cannot switch it off for my site only, and in the knowledge base there is a method of disabling through .htaccess, but I would have to turn off php-cgi which I am not going to do. There was also a way of including some php code in all of your php pages that would clear the globals, but what about php pages I get from others (ie wiki, wordpress)? And I certaintly do not want to change all of my php pages.

I feel very uneasy putting up my site with this enabled, which really only consists of a wordpress blog and some academic papers, but I still don't like the idea.

So, am I being paranoid or have others found a way to deal with this problem?

This is from the ini_set() part of the PHP manual.

In reply to:

register_globals boolean

Whether or not to register the EGPCS (Environment, GET, POST, Cookie, Server) variables as global variables.

As of PHP 4.2.0, this directive defaults to off.

Please read the security chapter on Using register_globals for related information.

Please note that register_globals cannot be set at runtime (ini_set()). Although, you can use .htaccess if your host allows it as described above. An example .htaccess entry: php_flag register_globals off.

Note: register_globals is affected by the variables_order directive.

If using htaccess doesn't work, then you could put it in your scripts by looking for the include file that is in all scripts. Most PHP scripts include one file that then includes lots of others. Look in the /inc/ folder if there is one, or config.php file. You could then put ini_set("register_globals", FALSE); in the file and should disable it for those scripts. Not sure if this will make a difference for security though for you.

Is this kbase blurb and comment out of date?

Good luck,

BobS

I believe he already covered all of the above in his post ;)

.htaccess vs. php-cgi. global setting vs. editing individual files. And the like.

decswxaqz had a good point though about hunting down if there's an include file that you can change. That might work. But it's still a kludge. But it's a kludge that works.

> I just switched to dreamhost and to my horror
> learned that register_globals is still enabled.

Indeed it is very disappointing. I'd like to hear from DH what sense they think there is in leaving register_globals enabled while e.g. disabling allow-url_fopen, causing grif dor itself and its users recently.

In reply to:
Indeed it is very disappointing. I'd like to hear from DH what sense they think there is in leaving register_globals enabled while e.g. disabling allow-url_fopen, causing grif dor itself and its users recently.

The lack of supported code.

You'll be surpised on the number of applications out there that still require Register Globals. OSCommerce is one of them!

Quite simple, even though PHP.net told everybody to *stop* using register_globals, people still used it. I got into a fight with a co-worker cause I disabled them on our intranet set (and this was recent!). People don't understand or just too lazy. Either way, it's due to others, not DH themselves.

It wasn't until the release of PHP5, turning it off by default, did users and developers finally worry about register_globals.

> the number of applications out there that still require...

That didn't stop DH disabling allow_url_fopen, a far less risky feature.

In reply to:
That didn't stop DH disabling allow_url_fopen, a far less risky feature.

Actually, a combination of the two is the worst-case scenario. See this example.

In reply to:
That didn't stop DH disabling allow_url_fopen, a far less risky feature.

I believe it's safe to say that far more applications require register_globals (including some scripts that DH supplies in their OneClick) than scripts that required allow_url_fopen.

In reply to:
I believe it's safe to say that far more applications require register_globals (including some scripts that DH supplies in their OneClick) than scripts that required allow_url_fopen.

I agree. DreamHost would have had a full-scale revolt on its hands if it disabled register_globals, because so many of today's (bad) applications rely on the directive.

I do think, however, that there should be some sort of roadmap put in place that will lead us to the disabling of the directive. I've long thought that DreamHost should set aside servers for certain groups of customers who can handle these sorts if changes. I would prefer to be hosted on a server that ran PHP5, with register_globals disabled.

At the very least, the disabling of register_globals should be in the list of suggestions.

Indeed, but that combination also requires "include", note.

A combination of register_globals and many other program features can be as bad. allow_url_fopen is not a necessary element of such an insecurity. It is not in itself remotely insecure. register_globals is inherently insecure. That's why it I'm disappointed that DH have "fixed" this problem by barring allow_url_fopen, breaking responsible apps, rather than register_globals, as most other reponsible ISPs have done. I'd far rather the DH shared server my sites run on was freed of the who class of register_global risks.

No surprise there, since I believe it is safe to say that there are more badly written programs that well written programs, period.

As a few other people have pointed out, turning off register_globals breaks lots and lots of scripts, and the kind of people it will break scripts for will not be able to fix them.

If you don't like register_globals, you're more than welcome to compile your own PHP binary that turns it off! I don't think most other hosts (especially of our size) that let you do cool stuff like that.

And register_globals isn't really inherently insecure, either. It's stupid, definitely, but it's only dangerous if you're not initializing variables with a known value.

nate.

> As a few other people have pointed out, turning off register_globals breaks lots and lots of scripts,
> and the kind of people it will break scripts for will not be able to fix them.

Um, surely the PHP4 default is OFF, and register_globals is ON for DH only because DH have changed it to ON. Had DH not done so, there wouldn't be any breakable scripts under PHP4 in the first place.

> If you don't like register_globals, you're more than welcome to compile your
> own PHP binary that turns it off!

That won't turn it off for the other users' scripts that degrade the performance of the shared servers, and degrade the performance of the provider itself.

I'd have thought twice about moving to DH had I known DH had changed register-globals from its default OFF. Not least because I'd not expect to get the service I need from a company that put the requirements of those who want to run unsafe scripts above those of responsible users. Having said that, I've been pleasantly surprised so far! But I do note that DH have reported problems and undue Support load which would not occur had they not made this change.

It would be nice to hear what plans DH have in this area. Including reassurance it won't be changing the register_globals default for PHP5.

In reply to:
> As a few other people have pointed out, turning off register_globals breaks lots and lots of scripts,
> and the kind of people it will break scripts for will not be able to fix them.

Um, surely the PHP4 default is OFF, and register_globals is ON for DH only because DH have changed it to ON. Had DH not done so, there wouldn't be any breakable scripts under PHP4 in the first place.

A lot of scripts are not written by the people that run them. Since a lot of those scripts weren't written on DH servers and a lot of them were written a long time ago, a lot of them expect register_globals to be on.

If we wrote every script or hosted every website, it wouldn't be a problem. Unfortunately, we don't!

In reply to:
That won't turn it off for the other users' scripts that degrade the performance of the shared servers, and degrade the performance of the provider itself.

Man, and you're a PHP programmer?

As far as I'm aware, most large web hosting companies have register_globals on for the same reason we do: it used to be the default, and a lot of our users expect it.

In reply to:
It would be nice to hear what plans DH have in this area. Including reassurance it won't be changing the register_globals default for PHP5.

Since PHP5 breaks tons of old PHP4 scripts, yeah, we're guessing it won't be a big deal to turn off register_globals. Can you tell what a huge, huge fan of PHP I am?

And again, there is nothing inherently wrong with register_globals. It only makes it easier to do stupid things.

nate.

> Since a lot of those scripts weren't written on DH servers

I can't see what that's got to do with it.

> and a lot of them were written a long time ago, a lot of them expect register_globals to be on.

Then they were written pre PHP4, and perhaps DH should have left them running on pre PHP4, rather than tinker with the PHP4 config. Things move on - PHP4 changed the register_globals for good reason - and DH can't hold back that tide.

> As far as I'm aware, most large web hosting companies have register_globals on

I thought otherwise, for PHP4 - i.e. most stick with the default.

> Since PHP5 breaks tons of old PHP4 scripts, yeah, we're guessing it won't be a
> big deal to turn off register_globals.

Thanks, but what's with this "turn off"? I'm not suggesting DH "turn off" - just leave the default "off" unchanged. Esp since surely DH won't be replacing the earlier version of PHP, even though IIUC it did last time around.

> Can you tell what a huge, huge fan of PHP I am?

Yup!

> And again, there is nothing inherently wrong with register_globals. It only makes it
> easier to do stupid things.

What's /inherently/ wrong with it is that, MUCH more than making it easier to do stupid things, it makes it easier to do dangerous things /by/ /accident/ e.g. though simply omission. In this it differs greatly from allow_url_fopen, note.

Edited by chrisjj on 05/25/05 04:51 PM (server time).

In reply to:
Um, surely the PHP4 default is OFF, and register_globals is ON for DH only because DH have changed it to ON. Had DH not done so, there wouldn't be any breakable scripts under PHP4 in the first place.

Wrong: On PHP4's release register globals was default on. In PHP 4.2.0, they turned it to default off.

And since you're whole argument seems to be based around the fact that it's always been default off in PHP4, there's nothing more that needs to be said.

> And since you're whole argument seems to be based around
> he fact that it's always been default off in PHP4

Read again.

Read again.

In reply to:
Then they were written pre PHP4, and perhaps DH should have left them running on pre PHP4, rather than tinker with the PHP4 config. Things move on - PHP4 changed the register_globals for good reason - and DH can't hold back that tide.

Incorrect assumption. They could have very well be written for PHP4. As I've pointed out, on PHP4's release, register_globals was turned on as a backwards compatability thing with PHP3 and PHP.net *pushed* people not to use register_globals, but since many books were still written for PHP3, novice PHP developers never saw that and continued to use them.

I happen to be sitting right next to such a novice developer in which I had a fight with cause I turned off register_globals on our intranet. /boggle

In reply to:
Thanks, but what's with this "turn off"? I'm not suggesting DH "turn off" - just leave the default "off" unchanged. Esp since surely DH won't be replacing the earlier version of PHP, even though IIUC it did last time around.

Default was On with PHP4 until 4.2.0. They may have kept with the same configs used by the initial release of PHP4.0. So in fact, if they'd had it off, they would have to "turn it off".

In reply to:
nate: As far as I'm aware, most large web hosting companies have register_globals on for the same reason we do: it used to be the default, and a lot of our users expect it.

Sounds reasonable to me. Although I would add to the fact for backwards compatability of originally built PHP4 scripts, too.

It's safe to assume all scripts are built for PHP4 or up these days. It's not safe to assume that they were all built for PHP4.2.0 as many novice PHP developers were completely unaware that register_globals was turned off, by default, in 4.2.0+ and expect register_globals to be on per 4.0's original defaults. PHP5.0 is, infact, changing that expectation.

Is there more that I should be reading here? Your argument is that PHP4's default is Off, which isn't exactly the case. Pre4.2.0, it was infact defaulted on. And DH should have kept it at it's default setting (off -- actually 'on') when any saine web administrator will be using the same php.ini file per PHP version (php3, php4, php5). And not worry about copying the php.ini-dist after *every* install of PHP cause they "might" have changed something to a developer's benefit.

So, in closing, register_globals was on in PHP4 by default until 4.2.0. You can assume through a reasonable guess that if they've had PHP installed since pre4.2.0, they are using the same php.ini which would conclude that setting it off would infact mean they would have to "turn it off".

In reply to:
Since PHP5 breaks tons of old PHP4 scripts, yeah, we're guessing it won't be a big deal to turn off register_globals. Can you tell what a huge, huge fan of PHP I am?

I've actually hadn't had too many scripts break in the upgrade to PHP5. As a matter of fact, I upgraded a website to PHP5 and nothing what so ever broke. Yah, I was a bit shocked about that, too.

However, I will say that I did find a bug in nested array_walks. Appearently PHP5 is having a slight cow when nesting array_talks. Converting one of them to a foreach fixed my problem.

> Incorrect assumption.

OK PHP4.whatever. Whatever the version number, the point is that DH overrode the default of thethe version they chose.

> I turned off register_globals on our intranet.

Good for you! ;)

> It's safe to assume all scripts are built for PHP4 or up these days. It's not safe to assume
> that they were all built for PHP4.2.0 as many novice PHP developers were completely unaware

Fair enough. Now, can we have a server with a PHP /not/ knobbled to for security against said novice programmers?

In reply to:
OK PHP4.whatever. Whatever the version number, the point is that DH overrode the default of thethe version they chose.

Well, they overwrote the default allow_call_time_pass_reference, allow_url_fopen, upload_max_filesize and even *more* if you use the Apache/PHP Module (I was just basing off the CGI configuration). How is that any different than all the changes they've made? Only difference I see is that register_globals might very well have been on it's "default" setting when they initially created their default php.ini file.

In reply to:
Now, can we have a server with a PHP /not/ knobbled to for security against said novice programmers?

This I wouldn't mind, but I'm not pressing the issue. We can install PHP5 or PHP4 ourselves and use our own version of the php.ini file, so that's enough for me.

Besides, if they did install PHP5 on their end, you do know they'll highly recommend using it as a CGI anyway, which would make no difference in performance than you installing your own version.

And I've already put forth the request to install a PHP5 CGI binary in the similar fassion they have the PHP4 setup and allow people to convert their sites that way.

If you're really worried about the security of other users on your server, then you really should be using a dedicated server. The "vulnerability" in register_globals being on is so minute that one issue should not be your primary concern in server security. It's nothing comparied to some hacks I've seen.

However, here are some tips to protect you from outside users;
cd ~
chmod o-r .
chmod o-r domain.com
chmod g= .
chmod g= domain.com

Your website will still run while group users will have no access to your files and 'other' others will not be able to read anything within your directory. Execute bit needs to be there for some reason, probably cause the website isn't ran directly as root, not sure exactly w/out extensive testing on my part.

Hope you've gained a few things from this discussion. I've shown you avenues you can use to protect yourself and I hope you learn that DH cannot just turn something off w/out thinking about the repricutions on their actions onto their user's scripts.

> The "vulnerability" in register_globals being on is so minute that
> one issue should not be your primary concern in server security.

Clearly DH disagree, otherwise they surely wouldn't have made the recent allow_url_fopen change to protect against register_globals "ON" risks, at the cost of breaking safe user apps relying on allow_url_fopen.

> I've shown you avenues you can use to protect yourself

But not against the performance threats that are my concern in this thread.

> and I hope you learn that DH cannot just turn something off
> w/out thinking about the repricutions on their actions onto
> their user's scripts.

Oh really. Where was such thinking (e.g. advance warning to customers) when DH broke RSS Equaliser?

In reply to:
Oh really. Where was such thinking (e.g. advance warning to customers) when DH broke RSS Equaliser?

I would assume so. DH has yet to prove to me they are a company that makes rash decissions. All their discussions on the boards and what I've seen done showns they do think things through as much as they possibly can.

In reply to:
But not against the performance threats that are my concern in this thread.

There are no performance threats between having register_globals on or off. You lost me here. You talking about using mod_php vs using PHP CGI? Optimizations in PHP5 would possibly compensate any perforance loss going from mod_php4 to PHP5 CGI. I have yet to have any issues with performance with PHP5 on my sites.

> ... they do think things through as much as they possibly can.

> DH has yet to prove to me they are a company that makes rash decissions.

I hope the allow_url_fopen decision was an exception, then. Because, rash or not, the decision to disable an important fearute of PHP solely to protect users running insecure scripts from the consequence of DHs own risky decision to set register_globals ON, at the expense of those responsible users relying on that feature, does not bode well for us responsible users.

> There are no performance threats between having register_globals on or off.

Register_globals ON risks malicious code being executed on the server. Apart from the the threat to the integrity of the guilty site, its a threat to the performance of all sites sharing that server.

oops, forgot the 'not' in that statement. ugh

In reply to:
I hope the allow_url_fopen decision was an exception, then.

hum, do you realize that they turned it off almost two months after they've announced it?

It went down like so; They made an announcement they'll be turning it off almost immediately (I think next few days was the choice), but many said the next few days wasn't enough time. So DH pushed out the date a month. Come the month and it wasn't disabled until almost 1-2 weeks *after* the posted date.

I don't know about you, but I sure as hell don't call 1.5 months a "rash" decission.
(and this doesn't even include the time for the behind the scene talk to decide to turn that off in the first place)

In reply to:
Register_globals ON risks malicious code being executed on the server. Apart from the the threat to the integrity of the guilty site, its a threat to the performance of all sites sharing that server.

Actally, allow_url_fopen supplied *more* of a risk of running melicious code on the server (register_globals *not* required--although enabled can open more holes with this function). A user could litterally run an entire application of their own using allow_url_fopen by simply pointing it to a script/webpage that contained actual non-parsed PHP code.

Plus, few people are actually use register_global variables to run system level commands. It's SQL inject code that's the biggest thing. Sure there might be a few system level hacks from register_global, but not near as many as there was from allow_url_fopen. And it broke far fewer scripts by turning off allow_url_fopen than it did turning off register_globals.

allow_url_fopen isn't as "required" as you might think. There's still perfectly valid work arounds and most PHP scripts are designed to work within the scope of your site only.

The only reasons I see to use allow_url_fopen is to parse/scrape remote websites, track your product on somebody else's site or just poor use of fopen (using http when you could have used the absolute path). While I'm sure there might be more reasons, those are the only three that popped into my head.

The choise they made;
turn off allow_url_fopen and break a couple 100 scripts.
or
turn off register_globals and break a coupld 1000 scripts.

They chose the 100 option.

If they decide to turn it off, it's pretty easy to write your own register_globals script anyway. I did something similar with my site. I passed in an array of information and used the keys as values $array['number'] would become $number. You just have to make it reference the session, get and post variables instead.

In reply to:
If they decide to turn it off, it's pretty easy to write your own register_globals script anyway. I did something similar with my site. I passed in an array of information and used the keys as values $array['number'] would become $number. You just have to make it reference the session, get and post variables instead.

You know, you just made me think of something:

Apache has the ability to auto-append or auto-preappend files to every file request, based on type, extension, etc.

Would it possible to do register_global emulation? Pre-append a register_global script converter to all scripts PHP, by default, and have a check box, in the CP, to allow users to disable that (and have it disabled by default).

This would allow you to turn off register_globals and still have it "enabled".

It's a thought that's not 100% thought through, but something worth looking into, no?