Critical PHP Update

4.4.1 released; includes important security updates

[AlexK]

Release Announcement here [php.net]
Info on $GLOBALS overwrite issue here [hardened-php.net] (took me a few readings before I started to get the point).

[ergophobe]

Thanks for catching that one AlexK

I have to say the $GLOBALS array has always made me a bit uneasy (not because I suspected a problem, just because globals of any sort used out of scope make me uneasy). Update or no, I think I'll avoid it unless absolutely necessary.

[grandpa]

What are the chances that this update will get rolled out through the various web hosts? I'm thinking little to none for most of them.

The best solution may be to read the specs for the update and, as ergophobe pointed out, avoid those things that the update is fixing when you write a script.

[madmac]

register_globals have always had problems and potential exploits when enabled... this one seems no different and is only possible when register_globals is on.

Just code your applications to only run with register_globals disabled and avoid past, present, and future exploits like this ;)

[AlexK]

madmac:

just code your applications to only run with register_globals disabled

Re-read the articles more carefully.

eg:

... disabling register_globals is not enough to fix this kind of vulnerability once and for all ...

That is the scary part of this, and I am still trying to absorb the impact of this info, even now. I must be slower than I thought.

[jatar_k]

>> I must be slower than I thought

hehe, I don't think so. I was reading around about this a few places and it does look like it is not so simple to exploit this but I agree it is fairly serious. The folk at hardened-php have a much higher level of familiarity with php than most.

This doesn't look much like a kiddie available exploit and would be more likely to be seen from a real hacker. True language exploits are seldom available to the scipt kiddie punks. If it doesn't get rolled to your host I wouldn't worry too much but always keep these things in mind when you are coding.

all data is suspect, trust nothing and no one

[madmac]

Alex, read within the context of the article (or at the very least that entire sentence instead of just the first 1/2 of it).

It is also necessary to understand, that disabling register_globals is not enough to fix this kind of vulnerability once and for all, because not only register_globals but also a lot of "register_globals compatibility layers" in a lot of applications are affected by this problem.

These applications usually emulate the function of register_globals...

According to PHP usage statistics 71.03% of all servers, that announce a PHP4 version within their HTTP headers, are still using PHP <= 4.3.10. This actually means that most of the servers out there are running with old versions of PEAR where a application gets automatically vulnerable if it includes PEAR.php and is running with register_globals turned on.

As I said, code your applications to ONLY run with register_globals disabled (and do not put any kind of register_globals emulator in) to avoid past, present, and future register_globals exploits, which is precisely the type of exploit this one is.

[AlexK]

What I am concerned about is the following kind of routine:

foreach( $GLOBALS ¦ $_REQUEST ¦ etc as $key => $value ) { 
 $GLOBALS[ $key ] = a_user_function_to_security_check( $value ); 
}

(Yes, I know that that is not valid PHP, but such a function, as one example, is within phpBB2 code)

If I understand the article correctly, even with the current updated-PHP *and* Register-Globals turned off, such a routine would switch Register-Globals back on. Now, as I said, I am still getting my head around it all, but that is my current understanding, and (from a security POV) it frightens the bejabers out of me.

Here is the relevant quote:

These applications usually emulate the function of register_globals by calling extract(), import_request_variables() or their own subroutine to merge the request variables into the global namespace. Therefore PHP4 >= 4.4.1 adds checks to extract() and import_request_variables() to protect them against overwriting the $GLOBALS variable. This however does not protect against applications that use their own routines to globalize

...which is exactly what the routine above is doing.

I welcome any help on this, please.

[madmac]

foreach($_REQUEST as $key => $value ) { 
 $GLOBALS[$key] = $value;
}

Well obviously that accomplishes pretty much exactly the same thing that register_globals = on does, and is therefore likely to be open to the same exploits that register_globals is victim to.

Just don't code like that. It's a poor practice and extremely insecure. [and don't use any apps that do program like that]. ;)

Unfortunately, it does seem many open source PHP apps are programmed like that and either use register_globals or emulate it. I don't know why they do or continue to do so, especially with all the current known register_globals exploits [and who knows how many lurking and waiting to be found]. I guess it [insecurity] is just the price you pay for open source PHP apps.

[AlexK]

Hmm. I've re-checked, and $GLOBALS[] is not used in phpBB2 at all. $HTTP_SESSION_VARS, whatever, is used, but not $GLOBALS, so that is a settlement (and sorry to inadvertently libel the phpBB2 developers).

Slowly, I am actually starting to get the point of this.