Security update: Rails 1.0, 1.1.3 not affected
Posted by David August 10, 2006 @ 04:38 AM
Good news: Rails 1.0 and prior is not affected by the latest security breach we’ve experienced. Neither is Rails 1.1.3. We’re currently investigating further just how contaminated 1.1.0, 1.1.1, 1.1.2, and 1.1.4 are. We’ll give you more updates as soon as we have the information. Our first priority has been to get a fix out, now we’ll get to the very bottom of this.
Believe you me, we take this extremely seriously. The entire core team is working on this investigation. We’ve currently made the trade-off to keep the details secret to protect people still in the process of upgrading. Once ample time for upgrading has been given and we have investigated this matter to its depth, we’ll release a complete report detailing all our findings.
Thank you for your patience and understanding. We fully understand that nothing can quite make your heart pump, as knowing there’s something wrong, but not being entirely sure what to do about it. It’s OK to vent that frustration in the comments to this post.
How about a maintenance release for each of the above versions? That’d seem to be the easiest and most useful for those of us running stable production apps.
Thanks, this is good to know. I’m running Typo 2.6.0 with Rails 1.0 frozen in vendor/. I was dreading the upgrade, as I would have to 1) build my own copy of Ruby 1.8.4 in my home directory (I’m on a shared host that only has Ruby 1.8.2) so I could 2) upgrade to Typo 4.0, and be able to use the new version of Rails.
I’d like to thank the rails team for their timely fix. Your efforts are greatly appreciated. I would also like to offer a bit of constructive criticism as I am certain this type of thing will happen again—to believe otherwise is just plain foolish.
I understand your desire to minimize the number of people who are bitten by this vulnerability. Having some time in which to patch your systems may seem reasuring, and to some small degree it is. Waiting to release more specific details keeps the vulnerability out of the hands of the simple malicious person whose havoc is only facilitated by their ability to copy and not truely understand that with which they use.
But this has little to no impact on a proficient programmer bent on causing harm. Some might argue it even serves as a challenge. By releasing the fix you have given them all that they need. Thus, invalidating or at least greatly reducing the effect of the period without disclosure.
Asking us to upgrade and believe all will be well without explanation places many of us in a difficult position, especially those using rails in a production or commerical capacity. Ultimately we are responsible for our own machines and ensuring the services we provide continue with minimum interruption.
Most of us are required by company protocol or at least bound by the obligations of good system administration practices to be able to properly identify affected versions, have an understanding of the severity of the vulnerability, and the vulnerability’s scope. That can’t happen without more specific disclosure.
Am I asking for full disclosure? Maybe. But probably not in this specific case. However, more specific details including ones that give a clue to the affected code such as, “if you’re using xyz then you will need to upgrade,” or, “if you cannot upgrade do the following as a work around,” better help me to guage the scope and severity of the vulnerabilty, while providing enough ambiguity to stop the casual cracker.
This process is not new and none of the arguments I presented are things that have not been already been discussed at great length. So I would hope that the rails community can learn from the other software projects and their handling of security vulnerabilities. Although there is no one solution, there are patterns of common behavior, reaction, and result that we can learn from.
:-)
Great work people, thank you!!!!!
Now, check this out:
“RadRails and SAP “http://www.radrails.org
Here is some ‘enterprise’ noise that rocks!!!! (I know you hate the enterprisey people, but I really would like to make money using Rails in a large corporate environment and wipe the smirk off the Oracle/SAP/Peoplesoft DBA’s faces.
Sorry for posting here, but I would like YOU to reference this news with the RADRAILS guys directly. Please. :)
In contrast to most other posts, I wish to express my thanks to David and the team in the way they’re handling this. The last thing Rails needs is lots of red tape, procedures, management woo-haa and formality.
Rails is a new and agile framework. If your company has adopted Rails, it surely has adopted a quick way of dealing with things or at least can be convinced of doing so.
Everyone running Rails should be up to date and on top of your game. Still running 0.13 for christ sake? Boo whooptie doo! Installing the new version literally took 2 seconds for me, zero problems, zero downtime. If there ever comes a ‘patch Tuesday’ for Rails with lots of approving nods from suits I will cry big fat tears of sadness (and move to a more agile framework).
I am anxious to read what the vulnerability is though.
Many thanks for officially clearing 1.0! This is a huge help to those of us with production systems (and Typo 2.6 instances) running on top of older Rails.
Looks like I’ll get to sleep tonight after all. :-)
For those of you with applications on Rails 1.1: I’ve seen the details of the security problem, and it’s nasty. Certain classes of Rails applications will be trivially exploitable, and the consequences will be extremely severe.
If there’s any way you can upgrade to 1.1.5, even at a slight risk of breakage, I strongly recommend doing so. Once the details get out, a large fraction of Rails 1.1 sites will be at significant risk.
Given how trivially this problem can be exploited, I think the Rails team is making the right call: Try hard to take advantage of this upgrade window, as imperfect as it is. Once the script kiddies figure this one out, you do not want to be unpatched.
Well, it’s a double-edged sword, since it’s open source (and the enterprising blackhatter can simply make a diff against the fix to try to figure out how to make an exploit). I know other security researchers often give developers advance notice before going public with their findings, so they can come up with fixes. I think Rails core should have kept quiet until they had completed all their research and totally narrowed it down and had a fix. I also don’t think it would have been prudent to fully detail what the security hole was right away (“adding ’?backdoor_password=12345’ to requests causes your server to be pwned! UPDATE IMMEDIATELY!”) so anybody and everybody could probably have easily exploited it.
As for venting, let me vent my appreciation to the Rails core for their hard work to address this issue!
I agree with the sentiment of the comment above by Trey. I have to say I’m somewhat disappointed with the response of the core team. Knowing that the fix is in 1.1.5, and that 1.1.4 is flawed it’s fairly easy for anyone to take up the challenge of figuring out the problem.
I don’t claim to be King Ruby of the Great Kingdom Metaprogrammalot but when dev.rubyonrails.org actually allowed an svn export (I’m sure traffic was heavy there for a while) of the 1.1.5 code then it took a negligible amount of time to use FileMerge to sort through the changes and find code changes that relate to the issue.
I would rather have known what the issue was right from the beginning because myself and others in the Rails community would have had patches for all applicable versions pretty quickly. I don’t see any great gains achieved by stalling disclosure like this, and anyone with malicious intent can figure out the problem just as easily as I did (though I had the intent of preventing an attack by the aforementioned type of person).
I do of course appreciate the fact that the security flaw was disclosed at all, and that there is a fixed version available. Thanks!
After updating Rails to 1.1.5, I got this whole bunch of routing errors when using components :( (i.e. those placed within the ‘components’ folder). E.g. I get “Routing Error… Recognition failed…” for the component’s path, say for example ”/blg/weblog/index”. Does anyone know the solution / location where I can troubleshoot this problem?
So what exactly is possible todo through this hole in safe_load_path()?
“It’s OK to vent that frustration in the comments to this post.” :
AAAhhhhhAAhhhh !
Is it OK like that ? Oh no that’s more like fear.
Frustration :
±±±Ô±‰ô‰ô≠%%¨/*M.+±#¥Ô–Ø„”–„ë}Ç{‰#Ô¥±#Ô±Ô‰#Ø–Û] !
Cats out of the bag.
http://blog.koehntopp.de/archives/1367-Ruby-On-Rails-Mandatory-Mystery-Patch.html
http://blog.evanweaver.com/articles/2006/08/10/explanation-of-the-rails-security-vulnerability-in-1-1-4-others
Time for full disclousre which is what we should have had at the beginning!
Do you also have to change this line in your environment.rb?
RAILS_GEM_VERSION = ‘1.1.4’
Thanks for the Info!
Could someone please take a look at the Engines problem. I assume a lot of people are using engines and a patch/solution would be a relief for me…
Any reasonably competent developer can figure out what the patch is without the core team going into details if it’s really that critical for you to do so.
I like the approach taken, namely, that of telling everyone to patch before releasing the details of the exploit. Of course, the evil hackers who are also technically proficient could figure out the hole anyway, but at least it keeps the script kiddies at bay.
I have to agree with the above comment. Diffing the two releases yields the changes and anyone really interested in doing damages only has to do that. I’d much rather have a fully disclosed description of the problem included with the patch so that I can know and see what’s going on. My company uses rails webapps to manage very sensitive information and there comes a point when not knowing what is going on almost puts rails out of contingency. Although I was able to read the diffs and figure out what was going on, I shouldn’t have to spend 4 hours of my afternoon assessing and reporting to my boss about what may or may not have happened. Good work though. :-)
So I called in an admin last night and we stayed up until the sun rose, quaffing four pots of coffee, so we could upgrade from 1.0 to 1.1.5, and we didn’t have to?
Bye bye, Rails.
Great, so I spent 3 hours I DIDN’T HAVE yesterday upgrading stuff from 1.0 that I didn’t have to update. Thanks a bunch
It has not been fixed. At least not on winxp using webrick.
See http://www.ruby-forum.com/topic/76671
Personally, I think, that this vulnerability is a good thing for the core team. They were so cheerful and confident teaching us how things should be done, and after all this criticizm on the web (regarding this issue) they should become more humble and modest.
Core team: cheer up, shit happens. And thx for Your great work.
Colin,
That may be true, but who is running a production website on winxp using a single-threaded interpreted webserver? If that setup is public facing, you deserve to get hacked.
Webrick is still vulnerable under linux also. Try accesing your http://localhost:3000/cgi directory.
As someone said on Slashdot, “Well, well. I’m not that afraid of kiddies who lack the clue to run diff.”
A better approach woul be to create a ticket explaining the problem, and let the community help provide patches. The only thing you are doing by not disclosing the bug is keeping some honest people in the dark.
Open it up; the cats out of the bag that it exists. Let the good guys help!
Can one simply rewrite the affected url’s until a patch comes out? I guess it can be quite hard since the vulnerability is pretty big (and deeply nested in the routing code).
It’s still not fixed right. See: http://www.ruby-forum.com/topic/76671#120478
Joost – Congratulations on your 2 second upgrade, you’re obviously not doing anything complicated. My team has wanted to upgrade rails ever since 1.1, but there were so many changes we cannot slow production at this point to attempt to fix everything, and when you’re overriding core code to fix problems, or just extend it to work for enterprise systems, it is not so easy!
As far as security disclosure, in agreement with most others on this post, to release a patch and not disclose the trouble to people is highly irresponsible. Check this comment for what I am talking about http://weblog.rubyonrails.org/2006/8/9/rails-1-1-5-mandatory-security-patch-and-other-tidbits#comment-11037 If anyone out there has had some of the issues we have you know there does not need to be any more reasons to make people leave ruby & rails. I love much of what it has provided my team, and we are not leaving yet, but let’s not allow this to happen again, ok?
Would a few more people bestow their brilliant insight regarding diffing svn patches?
Yes you’re right, its that easy. But it would have been a heck of a lot easier if they just handed out the how to hack rails manual.
It’s amazing that people are suprised theres a security hole in version 1.1.4!
I have successfully done gem update / rake rails:freeze:gems on RHEL 4. The same procedure on Mac OS 10.4.7 does not work for me. It refuses to unpack the 1.1.5 gem, instead unpacking the 1.1.4 gem. This command does work for me on OS X:
rake rails:freeze:edge TAG=rel_1-1-5
Only with rails do people thank the core team for bugs…great.
progress is good, and along the way things sometimes go wrong. that is ok. not learning from the things that have gone wrong in the past though is not. rails is great and so is it’s community, but can we please cut the “let’s release it now, we’ll fix it later” attitude?! patience is a virtue, and a key necessary to unlock the doors of true greatness.
Anyone having the engines problem, update your engines to http://svn.rails-engines.org/engines/branches/rb_1.1 for a temp fix.
For people in need of a workaround: You should be able to limit the damage, as far as I can tell, by making sure that you never have routes of the form:
Instead, try this:
Note to the core team: It’s past time to go public. The knowledge is all over the net, and continued secrecy is only hurting people who need to assess their risks before upgrading.
FYI: Mephisto runs of the completely rewritten routing and is unaffected by this issue.
http://www.ruby-forum.com/topic/76671#120478
Ok, that seems to bring down WEBRICK and lighttpd configs as well. A routes.rb rule doesn’t fix it either.
Exploits for 1.1.4 and 1.1.5 are available through very findable locations. Let’s open up now, guys, and give users the info they need to patch things up while you prepare 1.1.6 and backport fixes.
Rails is getting a big old black eye right now, time to make the info public and then immediately sit back down and create a plan for how to handle these things in the future.
On the other hand, this is a pretty effective way to limit enterprise adoption.
Between this:
http://www.flickr.com/photos/planetargon/127984254/
and this:
http://weblog.rubyonrails.org/2006/8/9/rails-1-1-5-mandatory-security-patch-and-other-tidbits
I am pretty mad. Do us a favor and grow up so we don’t look like idiots supporting this framework.
Thanks in advance.
yeah, where is the comment feed? why did it go away? it’d be nice to read these comments in my feed reader
I’ve gotta say, reading this post a day later is a bit annoying.
I realise the core wanted everyone to make sure everyone was now nice and safe by having them upgrade when they weren’t made aware of the actual problem, but I feel this could’ve been researched a bit more so we could come on to read a single post stating that only a select few versions were affected.
Instead there was a quick flash of panic, and everyone was running around trying to upgrade before some mystery hacker takes out every rails app in the world.
I personally waited to upgrade my app after reading the original post because I was interested in how this situation was going to develop.
The last few times I made a minor upgrade I was slapped with routing errors or some other issue that effectively broke my applications and caused a good bit of rewriting on my part.
I’m still looking forward to upgrading, but I think I’ll wait a bit before I roll this into production, as we turned out to be on the safe list in the end anyway.
Rails really needs a dedicated security announcement mail list (if it doesn’t already have one which I couldn’t find).
Oh, the list is created. Definitely a good move from rails team. I strongly believe this bad situation will make Rails stronger in the end.