Joomla! Discussion Forums

Well, the vulnerabilities were all very low risk so there is no significant threat. 

As for the suggestion, I have been thinking the same thing but I don't have any time available right now to put it together... maybe someone else can?

This upgrade has got a lot of people freaked out and that is unfortunate, it really is.  As is always the case, that is not the goal and is very much far from the goal but, it happens.  This change was included because the technology to break passwords has evolved at a frighteningly rapid rate.  6-9 months ago, rainbow tables were just an idea.  Today, they are widely available and extremely comprehensive.  For the greater security of Joomla! and the web, it was seen as a no-brainer decision... it had to be done.

Further, we could not anticipate that some of the bridge developers would just walk away and give up on the Joomla! community.  It is really unfortunate that has happened because in the end, everyone loses.  Joomla! loses, the community loses, the bridge builders lose.  I think rather than the community walking away in their stead, the community should step up and show that they want these guys to stick around.  They want to keep using their projects and they want to keep using Joomla!.

At any rate, it is unfortunate that this has created so many problems for so many people.  For that, I offer my personal apology.

From the Changelog:

* SECURITY A6 [LOW Level]: Fixed [#5630] HRS attack on variable "url"
* SECURITY A1 [LOW Level]: Fixed [#5654] Multiple fields subjected to cross-site scripting vulnerabilities
* SECURITY A7 [LOW Level]: Fixed possible session fixation vulnerability in administrator application
* SECURITY A4 [ LOW Level ]: XSS issue in com_search and com_content
* SECURITY A4 [ LOW Level ]: XSS vulnerability in mod_login

For me, these security fixes are more dangerous than an attack on the userpasswords with rainbowtables

Well, last time I checked Community Builder, VirtueMart and half a dozen other apps broken by this upgrade did NOT "just walk away and give up on the Joomla! community", so can we focus on them and once again, please leave our drama caps at the door? 

I am entirely sick of this sniping, as I know others are.  This isn't another thread about the GPL 'issue' so let's not let it become one.  Pick one of the thousand other ones and post your aggravation with 'some of the bridge developers' there please.  Geez...

You are right, I apologize, again.

I would like to point out that we did not just release this into the wild with no warning.  I personally sent an e-mail to Beat (CB) and Soeren (Virtuemart) on July 3rd to let them know that the changes were committed to the trunk and they would be in the release.  Obviously, this does not include all the bridge builders but they are two of the major ones and the only ones that are on our Quality & Testing team and the only ones that I have the personal e-mail addresses of.

Yeah, we probably should have sent an e-mail to more bridge developers or done something else to communicate the changes, we realize that now and you can consider it a lesson learned.  We will try to do better next time.

@RobS

Its not only bridge type components that are having problems - any "component" that uses a task called 'save' or 'apply' without a mosRedirect to wrap it up is badly affected in the backend.  I believe this is a bug in Joomla 1.0.13 (Joomla is failing to set the session cookie properly) - see http://forum.joomla.org/index.php/topic,193707.0.html . 

My main development tree is updated every 2 weeks from the SVN - its unfortunate that I didn't spot the problem before 1.0.13 was released 

Geraint

Geraint,

Thanks for bringing that to my attention, I will take a more in-depth look at the problem tomorrow and we can go from there but right now, it is bed time.

Rob,
I highly appreciate your clarification and no need for further apologies imho.
The try to do better remark is hopeful but not enough and allow me to explain why without personal- or offense at all... Trying to help as usual ;)

Process
The issue is that new release are done for instance to secure issues such as security, consistency, bug fixes etc. This is perfect and extremely important....end-users (and I am also an end-user) are mostly wildly enthusiastic at the moment something new of/from this fantastic product is released and want to play immediately with this new toy. The missing link here towards me as end-user is that I should have received a warning with the release that product X,Y,Z would be affected and that users had to wait till the X,Y,Z were updated. No offense but it was known that CB and VM were affected and it was very clear that Bridges and other stuff would be affected as well....(if login issues arise with CB and VM they will also arise on similar coded solutions) It was know upon release that CB and VM were not ready and THAT should have been communicated. I completely agree with the fact that "core" has patched the security holes as rapidly as possible and Beat was indeed the initiator for this and he was darn right...

I still agree that it should have been released asap it to secure the sites asap but the way how this is done now has caught the entire community by total surprise. Realize that we have the end-users (who spend just like you and me days and nights on discovering and building and spending tons of money of their savings on extensions or training or templates) who have contacted us (literally in tears) that everything they have done was (in their opinion) destroyed. So trying to do it better is not enough!   We must do it better!

Process impiovement
Core and Quality have enough methods to communicate with the entire development community. It is done for 1.5 so it could have been done with this release in advance as well. We have the best source available to make development announcements so developers could react in time and that is http://dev.joomla.org/... So email is never the best method.....(spam is one of those reasons....) So any message/signal could have been send out to the development community also early July on the Development Site? (note: Than the responsibility would have been with 3rd parties......)

The announcement should never be done after the software iis published.... That is the biggest issue what is causing much pain and needless problems for the end-users

>> Appoint a focus-person for 3rd party communications and bridging internal issues responsible for these releases

Testing
One of the major issues seems to me related to being kicked out of admin backend.  A Testing Team would have logged in in admin I assume and would have discovered this in advance? I know we have a testing team and they should also test 1.0.x versions (!) The person mentioned above could have an assuring task here?

Communication end-user
Allow people who work on daily basis and who "talk" daily with the real end-users to support and facilitate "readable and understandable" end-user announcements before they are published. I am sure you will be able to find these kinds of persons on the forum   Example:



I hope this is read as it should be ready namely not as critics but as positive contribution.............

Cheers and as always with respect for all efforts

Leo

Rainbow tables let you turn a hashed password into a password.

So, how would an attacker get a hashed Joomla password?

What is the scenario for this vulnerability?

Thanks,

David

Shocking News that my SMF Bridge will not work with the new upgrade........ and more shocking is to see that you guys are using SMF. You just lost a Joomla Fan!!

The reason for SMF not working with 1.1.13 is not related to the release of Joomla 1.1.13. This is related to a license issue on which SMF has withdrawn the support for their Joomla-Bridge before the release of 1.1.13.

It is fantastic that joomla has lots of extensions

But if joomla restricted its improvements to those that never broke functionality in 3rd party add-ons, then joomla would be in a very bad place indeed.

Although joomla should take extensions into account, it is the add-ons that need to follow joomla's lead.

Please everyone remember: Joomla did not do an automatic upgrade to your site without your permission.

It is your responsibility to test upgrades on your system - especially if you have add-ons

Yes - the joomla team should take reasonable care, but it is a volunteer project and you should not expect extensive testing of 3rd party extensions by them.

If you dont want to do that, then I suggest that you stick to a default installation of joomla with no mods.

As I said in an earlier post, if people just wait a couple of days after a release, they will see most issues arise.

As the famous rapper said,

- or something like that.

Joomla! Announcement for J! 1.0.13 entitled Austin ... the Joomla! has Landed - July 21, 2007, 11:15:30 AM by Manuman.

SMF Announcement to not support J! 1.0.13 entitled SMF Bridge for Joomla! Discontinued - July 24, 2007, 10:39:51 PM by Motoko-chan.



SMF's choice to discontinue the bridge was based on a very generic discussion with the FSF on combining GPL and non-GPL compliant software. Joomla! was not mentioned. The FSF's opinion was for *any* GPL environment, which would include Mambo, the only CMS named by SMF as a viable substitute. 

I deeply hope that SMF will rethink this approach. The announcement made on July 24 forces Joomla!/SMF end users to either a) use a CMS they did not freely choose or b) leave their sites vulnerable for the v 1.0.13 security fixes.

A reasonable transition period, perhaps six months to a year, would be very much appreciated and there is nothing stopping SMF from providing this time for these people.

Amy

HiYou also forgot translation teams... as usual I would say. Each 1.0 upgrade is quite a headache beacause of hardcoded language strings, I wish we would be warned a couple of days before official releases to ease the work. Hopefully this was the last time wa had to dig into the code 

@ RobS
Your apologies, though unnecessary IMHO are what sets folks like you apart.  You have not only my respect, but my gratitude for all you do.  As one of the thousands of long time users (and sort of part time dev), if there is anything we can do to help, let us know.

@leolam
Once again, you've done a fine job of cutting through the clutter and explaining the situation in easy to understand terms.  You also have my thanks!

@Amy
I bet you get tired of explaining these things over and over, but each time you make every attempt to do so in a positive and upbeat fashion, and try to provide solutions.  Another tip of my hat to you as well.

@toubkal
I think you really hit the nail on the head...it's really up to the users/devs in the community to test the over 1000 extensions in their own sandbox and report back their findings; it's damn near impossible for the release teams to be able to account for every possible scenario and still provide timely releases.

And finally @e1bot
If issues after the release of a ANY open source project is enough to make you "stop being a fan", then perhaps you are in the wrong environment.  Resolving issues together is what OSS is all about.  Where else to you get one on one with the actual developers to assist you in resolving those issues?  Not in commercial environments to be sure!

There were no changes to the language files for Joomla! 1.0.13.  Thus, nothing for you to do

I know there were no changes to the language file, but we had to update 30 core files anyway, those with french hardcoded strings...

To late for me... Anyway the low risk issues patch sounds great.

Man I feel bad

I feel it's a great shame that (yet again) we're facing a feature change in what's meant to be a maintenance release.

Yes, ok, so the developers of CB & Virtuemart knew about it (and I believe tried to block it), but the release of J 1.0.13 still means that I now have to update not one, but at least 2 different software components on my websites. (and if I'm using SMF as well....)

Every time I do an upgrade on Joomla (since 1.7) something else has broken. This should not this be the case in a maintenance release???

I fully agree with toubkal. I allways wait at least a week before I start updating production sites. As soon as an update is launched I update my testsite (on which several components run which have caused me problems with earlier updates), than I follow the forum threads about update issues.

With this release it was clearly stated that there were changes in the password storage. So I knew in advance that there could be problems with CB, forums and some other comps. This made me extra carefull. I'm still not sure if I'm gong to update all my sites. I've skipped versions before. Only with high risk security issuses I upgrade asap.

I agree with you! (Side Note: This reminds of that scene from Mel Brooks "Blazing Saddles" during the town meeting when each person heartily agrees with the person preceding them..."Tom Johnson is right.."..."Howard Johnson is right!"...)  I do the same thing, but we always need to keep in mind that Joomla! users run the gamut, and not everyone reads the announcements as closely as they should.

But what do you do?  Put the compatibility warning in big red bold type?  It appears the announcement was edited at least once and I don't remember if the original announcement stated the possible issues with compatibility as clearly as it does now (just my memory RobS, not accusing you of misleading anyone!)  but if you read the announcement as it now stands I don't know how you could blindly update and be surprised by the results.

I NEVER apply ANY update to ANY programs, Open source OR Proprietary without waiting a day or two for the early adopters (aka "suckers") and seeing the support threads associated with it.  The I test it on my own sandbox first before deploying it.  Been doing it that way for decades and see no reason to change a method which has served me so well...

This regretfully is NOT the fact. The initial release was made together with the 1.5.RC release announcement and snowed under completely without referring to anything what might be a problem....... I described that before and suggested and proposed improvements on which so far non of "core" feels the need to react which is very, very disappointing......

cheers

edit: You are an experienced user it seems but how could all those newbies and starters and non experienced users know that "password storage changes" would have impact at all? Come on!!!!

I received an email about the release on 24 july containing this information:
Joomla! 1.0.13 [ Sunglow ] is now available for download.

Joomla! 1.0.13 features:

Several low-risk security fixes
Improved password storage system
Easier control over Register Globals Emulation
An Itemid backwards compatibility setting
Improved administrative session security
Improved HTTP/HTTPS switchover support

That's what I was refering to.

fully accepted of course...That email was send after initial release with loads of problems. The release was posted in the announcement of 1.5.RC at the bottom:
All files were released together with this and only 1 1/2 day later after huge problems with end-users and loads of communications with loads of Moderators finally the decision was made to place the warning out with a separate release...and that S***s big time

Thats where I was referring to

cheers

edit: typo's

I am confused on this. Are you saying that RobS's more formal announcement would not have happened if there weren't problems and pressure from moderators? I don't know if you realize this, but there are a couple of events that Rob, in particular, attended for Joomla!. One was in Texas and the other is in Oregon - travel in between. I guess I was assuming that those events might be, in part, reason for a delay in a formal announcement. I don't know, I didn't ask.

The early announcement went out on Saturday and it is true - it was not a typical *blaring* - come and get it! - v 1.0.13 is available announcement. It was, indeed, tucked away into the bigger v 1.5 announcement and one had to read the entire announcement to find it. And, even then, it wasn't immediately obvious to me.

I was here helping people, too. In many ways, it turned out to be advantageous to have time with a smaller group of community members to identify integration issues. By the time the bigger "call" was made - 36 hours later - we were better prepared.

I am just not at all certain there is a *right way* to do all of these things. I am certain we can always improve. But, there is quite a bit going on right now and we might need to be a little more flexible and understanding.

Anyway, just my perspective,
Amy

It seems that the password change is the main reason one might apply this fix.  I would like to know if it is worth doing so.

I can't figure out how an attacker would get a hashed password; without that, rainbow tables are irrelevant.

Can someone please say how hashed passwords are exposed?

Thanks,

David

was waiting for that one of yours...just could not resist could you? (no smile)  : Amy no comment see >  http://forum.joomla.org/index.php/topic ... #msg920286

To clarify, I intended to have a more in-depth announcement as part of the Joomla! 1.5/Austin JoomlaDay announcement but when it was being prepared I was driving through the middle of the desert so I wasn't around to help with the announcement or give feedback. 

As for the actual issue with getting passwords, it is a combined vulnerability.  It takes another vulnerability, most likely an SQL Injection, that will allow an attacker to get all your user information.  Then, they have a high probability of being able to break the md5 hashes using the rainbow table technology and once that happens, they have full and complete access to your website and can do anything that you can do.

But aren't the passwords transmitted in the clear across the net, or are they passed as hash?

ROTFLMAO

and therein lies the rub (but it's really a numbers game as far as this fix -- protect in mass as opposed to the onesy twosy login sniffs)

yeah, on most people's installations, they are passed cleartext except for those webmasters implementing SSL for their logins.

in order to break the hashes, the DB would have to be compromised (as Rob pointed out).  However, a compromise of the DB is probably less likely than exploitation of those other low level fixes (which BTW, I second the notion of those fixes being made available if possible).  Getting the DB is not a simple thing to do, unless you might also be on a shared server with other people's accounts or unless you've been exploited thru SQL injection and a few other unlikely exploits (or poorly configured settings).




This pw issue is one of those things I'd consider low risk, but very high impact, especially if someone compromised your entire userlist.  Cuz if they got all your hashes, they could probably decode a good percentage of them fairly easily.  Rob is right that a lot of strides have been made in the password cracking arena lately, but I want to clarify that this is mostly with respect to MD5 hashes and even SHA1 hashes.  The concept of Rainbow tables has been around much longer than 6-9 months ago (they in fact have been used to continually improve the speed of breaking Windows LANMAN hashes for at least 8 years as far as I know).

The urgency for Joomla's new password strength is specifically due to greater exposure of MD5's weaknesses (the pw hash for Joomla).  Salts make a huge difference and I'm glad they went that route as opposed to just a stronger hash (ie SHA2 or something).  After thinking about this from a standpoint of such high impact despite the low risk, I fully support the team's decision to implement this painful fix.  At 1st I personally might've thought that they should offer a backend configuration option to choose the password security strength for backward compatibility sake, but looking at the impact of essentially having most of your passwords cracked is almost as bad as having them cleartext.  I think thats enough reason for the community to just bite the bullet and nip this vulnerability in the bud sooner than later.

I think Louis coded the logic for how it phases in the salts and honestly (after reviewing those changes myself, over and over again), I think that was the best way it could've been done w/o forcing a jos_user table update in conjunction with the upgrade.