Components not working with Register Globals Emulation off

[Websmurf]

Updated the list again.

[mjvvorst]

Beat,

Thanks very much for your fixes that seem to work very well! Many in the community profit from your efforts.
CB & Joomlaboard work perfectly, but in Akocomment there is still a little glitch: with RG-EMULATION off, comments can no longer be deleted in the backend!
Mark

[tyler]

Beat,

Thanks very much for your fixes that seem to work very well! Many in the community profit from your efforts.
CB & Joomlaboard work perfectly, but in Akocomment there is still a little glitch: with RG-EMULATION off, comments can no longer be deleted in the backend!
Mark

My sentiments exactly Beat.  I did confirm the fix to now work on the front-end w/RG emulation off.  However, I did not test backend yet, though I'm sure mjvvorst's backend  AkoComment problem will be the same as mine (ie. unable to delete AkoComments w/RG emulation off).

[Beat]

Beat,

Thanks very much for your fixes that seem to work very well! Many in the community profit from your efforts.
CB & Joomlaboard work perfectly, but in Akocomment there is still a little glitch: with RG-EMULATION off, comments can no longer be deleted in the backend!
Mark

In my version of AkoComment the buttons to delete were missing in the code.
I added that code, but as it's not GPL, I can't publish it.
I'm adding to my post above the code for making backend work with RG_EMULATION.

[mjvvorst]

Beat,
Works like a charm in the backend. Thanks!
At this time of night....do you ever sleep !?

[fan2]

Hello,
I am using CB 1.0RC2 with SMF Bridge.
It appears that there are some issues in Single-Signon in the SMF bridge if you upgrade CB 1.0RC2 to 1.0.1.

The php register_globals variable is set to ON.

But i have set the RG_EMULATION to 0 in globals.php

Also, in my .htaccess file, i have added  the following :

Code: Select all

########## START
# Block out any script trying to set a mosConfig value through the URL
RewriteCond %{QUERY_STRING} mosConfig_[a-zA-Z_]{1,21}(=|\%3D) [OR]
# Block out any script trying to base64_encode crap to send via URL
RewriteCond %{QUERY_STRING} base64_encode.*\(.*\) [OR]
# Block out any script that includes a <script> tag in URL
RewriteCond %{QUERY_STRING} (\<|%3C).*script.*(\>|%3E) [NC,OR]
# Block out any script trying to set a PHP GLOBALS variable via URL
RewriteCond %{QUERY_STRING} GLOBALS(=|\[|\%[0-9A-Z]{0,2}) [OR]
# Block out any script trying to modify a _REQUEST variable via URL
RewriteCond %{QUERY_STRING} _REQUEST(=|\[|\%[0-9A-Z]{0,2}) [OR]
# Block out any script trying to modify a CONFIG_EXT variable via URL
RewriteCond %{QUERY_STRING} CONFIG_EXT\[LANGUAGES_DIR\](=|\[|\%[0-9A-Z]{0,2})
RewriteRule ^(.*)$ index.php [F,L]
########## End - Rewrite rules to block out some common exploits

Do you think i am temporarily protected agains any hack via CB 1.0RC2 before i find a solution about the bridge ?

Thanks for your help.

[tyler]

Beat,
Works like a charm in the backend. Thanks!
At this time of night....do you ever sleep !?

I tested the same backend AkoComment scenario, both with and without Beat's hotfix,... and his hack makes all the difference, yet again!   My RG emulation is off BTW

[Beat]

Beat,
Works like a charm in the backend. Thanks!
At this time of night....do you ever sleep !?

Thanks...
Working on this
http://dev.joomla.org/index.php?option= ... d=33&p=168
with Rey and others keeps me awake tonight...

[Beat]

Hello,
I am using CB 1.0RC2 with SMF Bridge.
...
Do you think i am temporarily protected agains any hack via CB 1.0RC2 before i find a solution about the bridge ?

Thanks for your help.

This .htaccess file should protect you from the most critical vulnerability of RC2. RG_EMULATION 0 doesn't have an influence there, but register_globals OFF (REALLY RECOMMENDED SETTING!) or furl_open OFF would also protect you.

CB 1.0.1 includes other security fixes as well, so I would still look for a solution to your problem to be able to upgrade in the near future.

[lewisteo]

Something I found useful is Team Calendar Pro from www.lewe.com, but to my disappointment this component requires Register Global = on, if not it will not function accordingly.

I had spent much time updating the codes with $_SERVER["PHP_SELF"] for declared $PHP_SELF but still had not got the 2.8.001 version to work productively.

I was wondering someone could look into this interesting component and see if help can be rendered for it.

Thanks in advance.

[fan2]

Hello,
I am using CB 1.0RC2 with SMF Bridge.
...
Do you think i am temporarily protected agains any hack via CB 1.0RC2 before i find a solution about the bridge ?

Thanks for your help.

This .htaccess file should protect you from the most critical vulnerability of RC2. RG_EMULATION 0 doesn't have an influence there, but register_globals OFF (REALLY RECOMMENDED SETTING!) or furl_open OFF would also protect you.

CB 1.0.1 includes other security fixes as well, so I would still look for a solution to your problem to be able to upgrade in the near future.

Thanks BEAT,
As soon as i know that there will be no problem when i upgrade CB1.0RC2 to CB1.0.1, i will do it.
About the PHP register_globals, the hoster does not want to modify it.

[tomww]

Hello
i ve problems in joomlaboard with uploading files and pics. (after rg_emulation off)

does it works in yours?

Tom

[MarHaj]

Provided the first Akocomment BEAT fix concerns akocomment.php and the second admin.akocomment.php I am affraid that for tweaked Artistworks.net version of Akocomment 2.0 they do not work.

But, in the name of those who use non tweaked version: Beat, THANKS!! You saved our sites (and souls)!!!

[Beat]

...
About the PHP register_globals, the hoster does not want to modify it.

My free advice: change hoster when you can, that one seems not to understand basic PHP security (or server config)  in year 2006.

[kunglao]

With RG_EMULATION OFF, the Joomlaboard topic subscription doesn't seem to work as well. 

That is, one can't register to a new topic.  The request is accepted but the database/status is not getting updated. 

If RG_EMULATION is set back to ON, there's no problem.

Is anyone else experiencing the same problem ? 

Thanks,

[tyler]

With RG_EMULATION OFF, the Joomlaboard topic subscription doesn't seem to work as well. 

That is, one can't register to a new topic.  The request is accepted but the database/status is not getting updated.   

If RG_EMULATION is set back to ON, there's no problem.

Is anyone else experiencing the same problem ? 

Thanks,

I have the exact same issue with being unable to add OR unsubscribe topic subscriptions with RG emulation off

[kunglao]

With RG_EMULATION OFF, the Joomlaboard topic subscription doesn't seem to work as well. 

That is, one can't register to a new topic.  The request is accepted but the database/status is not getting updated. 

If RG_EMULATION is set back to ON, there's no problem.

The fix that seems to work for me is to append the following to Beat's fix sequence in joomlaboard.php

Code: Select all

if (!isset($sb_thread) && isset($_REQUEST["sb_thread"])) 	$sb_thread 	= mosGetParam ( $_REQUEST, 'sb_thread'  , ''); 
if (!isset($thread) && isset($_REQUEST["thread"])) 	$thread 	= mosGetParam ( $_REQUEST, 'thread'  , ''); 

Somehow, #_POST wouldn't work but $_REQUEST does.
Since I'm new to this, I'd appreciate expert members to validate the fix.

Thanks in advance,

[tyler]

The fix that seems to work for me is to append the following to Beat's fix sequence in joomlaboard.php

Code: Select all

if (!isset($sb_thread) && isset($_REQUEST["sb_thread"])) 	$sb_thread 	= mosGetParam ( $_REQUEST, 'sb_thread'  , ''); 
if (!isset($thread) && isset($_REQUEST["thread"])) 	$thread 	= mosGetParam ( $_REQUEST, 'thread'  , ''); 

Somehow, #_POST wouldn't work but $_REQUEST does.

thx for sharing kunglao, that fix seems to be working for me too

[RobS]

$_REQUEST is just a more general array that contains the contents of the $_POST, $_GET, and $_COOKIE arrays... best used when you aren't sure whether the request will be in Get or Post format...  There shouldn't be any problems with its use in that scenario.

[Beat]

With RG_EMULATION OFF, the Joomlaboard topic subscription doesn't seem to work as well. 

That is, one can't register to a new topic.  The request is accepted but the database/status is not getting updated.   

If RG_EMULATION is set back to ON, there's no problem.

The fix that seems to work for me is to append the following to Beat's fix sequence in joomlaboard.php

Code: Select all

if (!isset($sb_thread) && isset($_REQUEST["sb_thread"])) 	$sb_thread 	= mosGetParam ( $_REQUEST, 'sb_thread'  , ''); 
if (!isset($thread) && isset($_REQUEST["thread"])) 	$thread 	= mosGetParam ( $_REQUEST, 'thread'  , ''); 

Somehow, #_POST wouldn't work but $_REQUEST does.
Since I'm new to this, I'd appreciate expert members to validate the fix.

Thanks in advance,

Thanks for proposing fix and also for confirming. Added to the other fixes in my post to group them together

[tyler]

the latest JoomlaBoard fixes do not cover the ability to post attachments w/RG off as far as my tests have shown.

When I set RG emulation back to on, the attachment uploads work again.

Can anyone else confirm this on w/the latest JoomlaBoard and RG emulation OFF?

[Beat]

the latest JoomlaBoard fixes do not cover the ability to post attachments w/RG off as far as my tests have shown.

When I set RG emulation back to on, the attachment uploads work again.

Can anyone else confirm this on w/the latest JoomlaBoard and RG emulation OFF?

Confirmed...files + images didn't work + "subscribe me" option on posts/reply.

Fix below fixes that: add to joomlaboard.php other fixes this:

Code: Select all

if (!isset($subscribeMe)	&& isset($_POST["subscribeMe"])) 	$subscribeMe 	= mosGetParam ( $_POST, 'subscribeMe'  , ''); //BBTEMPFIX
if (!isset($attachimage)	&& isset($_FILES['attachimage'])) $attachimage	= mosGetParam ($_FILES['attachimage'], 'name', ''); //BBTEMPFIX
if (!isset($attachfile)	&& isset($_FILES['attachfile'])) $attachfile = mosGetParam ($_FILES['attachfile'], 'name', ''); //BBTEMPFIX

Adding to my post http://forum.joomla.org/index.php/topic ... #msg441456

Can you please confirm the fix fixes all three functions ?

EDIT: changed code above.

[Hackwar]

Hey Beat,
don't forget the fix I send in. You have to add this on line 170 of /administrator/components/com_joomlaboard/admin.joomlaboard.php for viewing user details:

Code: Select all

$uid = mosGetParam( $_REQUEST, 'uid', array(0) );
if (!is_array( $uid )) {
   $uid = array(0);
}

[tyler]

the latest JoomlaBoard fixes do not cover the ability to post attachments w/RG off as far as my tests have shown.

When I set RG emulation back to on, the attachment uploads work again.

Can anyone else confirm this on w/the latest JoomlaBoard and RG emulation OFF?

Confirmed...files + images didn't work + "subscribe me" option on posts/reply.

Fix below fixes that: add to joomlaboard.php other fixes this:

Code: Select all

if (!isset($subscribeMe)	&& isset($_POST["subscribeMe"])) 	$subscribeMe 	= mosGetParam ( $_POST, 'subscribeMe'  , ''); //BBTEMPFIX
if (!isset($attachimage)	&& isset($_POST["attachimage"])) 	$attachimage	= mosGetParam ( $_POST, 'attachimage'  , ''); //BBTEMPFIX
if (!isset($attachfile)		&& isset($_POST["attachfile"])) 	$attachfile		= mosGetParam ( $_POST, 'attachfile'  , ''); //BBTEMPFIX

Adding to my post http://forum.joomla.org/index.php/topic ... #msg441456

Can you please confirm the fix fixes all three functions ?

Hmmm, the image and file upload do not work for me when using that fix w/RG emulation off, but the subscribe to thread option does work in that scenario.  I even tried a version of those fixes where $_POST is changed to $_REQUEST and I got the same non-working results for img & file uploads.  This is w/RG Emulation off.  Works fine with RG Emulation off.

[tyler]

is it possible that maybe the $_FILES var needs to be adjusted for RG?  Was looking a little bit in the joomlaboard file_upload.php & image_upload.php and saw $_FILES used there.

not sure what to tinker with it though to make it recognizeable under RG off

and as I mentioned earlier, the subscribe me does work, just not the file or image uploads for me.

[kunglao]

and as I mentioned earlier, the subscribe me does work, just not the file or image uploads for me.

I confirm Tyler's problem: "subscribe me" also works for me but not the file/image upload, even with  $_REQUEST.

kunglao

P.S.  Thanks to all for your previous feedback.

[kunglao]

To fix the joomlaboard file/image upload, this seems to work for me:

Code: Select all

if (!isset($attachimage)	&& isset($_FILES['attachimage'])) $attachimage	= mosGetParam ($_FILES['attachimage'], 'name', '');
if (!isset($attachfile)	&& isset($_FILES['attachfile'])) $attachfile = mosGetParam ($_FILES['attachfile'], 'name', '');

And in this case, given that $attachfile & $attachimage are used just like a flag in the code, can we not bypassing mosGetParam instead

Code: Select all

if (!isset($attachimage)	&& isset($_FILES['attachimage'])) $attachimage	= $_FILES['attachimage']['name'];
if (!isset($attachfile)	&& isset($_FILES['attachfile'])) $attachfile = $_FILES['attachfile']['name'];

Beat, Rob, or other experts, any reservation on either option ?

Thanks,

KungLao

[RobS]

You should always filter input to your PHP code.  The first code example which utilizes mosGetParam is the way you should be doing it... I suggest you apply the same practices to the second code example.

[Beat]

To fix the joomlaboard file/image upload, this seems to work for me:

Code: Select all

if (!isset($attachimage)	&& isset($_FILES['attachimage'])) $attachimage	= mosGetParam ($_FILES['attachimage'], 'name', '');
if (!isset($attachfile)	&& isset($_FILES['attachfile'])) $attachfile = mosGetParam ($_FILES['attachfile'], 'name', '');

And in this case, given that $attachfile & $attachimage are used just like a flag in the code, can we not bypassing mosGetParam instead

Code: Select all

if (!isset($attachimage)	&& isset($_FILES['attachimage'])) $attachimage	= $_FILES['attachimage']['name'];
if (!isset($attachfile)	&& isset($_FILES['attachfile'])) $attachfile = $_FILES['attachfile']['name'];

Beat, Rob, or other experts, any reservation on either option ?

Thanks,

KungLao

1) Kudos for the find of my stupid mistake in the fix . Actually the culprit using wrongly these variables is post.php  ;)

2) Both variants are strictly identical for now, as those variables are arrays, and that mosGetParams does not filter/modify arrays (its expected behavior until now).

3) I have carefully checked the files and image uploads in joomlaBoard from a security point of view using those parameters. The use in post.php is safe, as it's only testing if it's non-null values. I did not find critical vulnerabilities from this point of view (you need to check this when not using mosGetParameters).

Will update my posts above...

[tyler]

How about the following four other variables used respectively in image_upload.php & file_upload.php:

$_FILES['attachimage']['size']    --->  $imageSize
$_FILES['attachimage']['tmp_name']
$_FILES['attachfile']['size']      --->  $fileSize
$_FILES['attachfile']['tmp_name']

Should these need to be accounted for in the same or similar way?