Register_globals again!

wordpress

#1

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?


#2

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

[quote]
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. [/quote]

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.


#3

I believe he already covered all of the above in his post :wink:

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


#4

[quote]I just switched to dreamhost and to my horror
learned that register_globals is still enabled.

[/quote]

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.


#5

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.


#6

[quote]the number of applications out there that still require…

[/quote]

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


#7

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


Simon Jessey
Keystone Websites | si-blog


#8

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.


#9

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.


Simon Jessey
Keystone Websites | si-blog


#10

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.


#11

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


#12

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.


#13

[quote]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.

[/quote]

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.

[quote]If you don’t like register_globals, you’re more than welcome to compile your
own PHP binary that turns it off!

[/quote]

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.


#14

[quote]> As a few other people have pointed out, turning off register_globals breaks lots and lots of scripts,

[quote]and the kind of people it will break scripts for will not be able to fix them.

[/quote]

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.[/quote]
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!

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.

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.


#15

[quote]Since a lot of those scripts weren’t written on DH servers

[/quote]

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

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

[/quote]

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.

[quote]As far as I’m aware, most large web hosting companies have register_globals on

[/quote]

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

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

[/quote]

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.

[quote]Can you tell what a huge, huge fan of PHP I am?

[/quote]

Yup!

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

[/quote]

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.


#16

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.


#17

[quote]And since you’re whole argument seems to be based around
he fact that it’s always been default off in PHP4

[/quote]

Read again.


#18

Read again.

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

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

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


#19

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.


#20

[quote]Incorrect assumption.

[/quote]

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

[quote]I turned off register_globals on our intranet.

[/quote]

Good for you! :wink:

[quote]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

[/quote]

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