Rails 1.1.5: Mandatory security patch (and more)
Posted by David August 09, 2006 @ 05:30 PM
We’re still hard at work on Rails 1.2, which features all the new dandy REST stuff and more, but a serious security concern has come to our attention that needed to be addressed sooner than the release of 1.2 would allow. So here’s Rails 1.1.5!
This is a MANDATORY upgrade for anyone not running on a very recent edge (which isn’t affected by this). If you have a public Rails site, you MUST upgrade to Rails 1.1.5. The security issue is severe and you do not want to be caught unpatched.
The issue is in fact of such a criticality that we’re not going to dig into the specifics. No need to arm would-be assalients.
So upgrade today, not tomorrow. We’ve made sure that Rails 1.1.5 is fully drop-in compatible with 1.1.4. It only includes a handful of bug fixes and no new features.
For the third time: This is not like “sure, I should be flossing my teeth”. This is “yes, I will wear my helmet as I try to go 100mph on a motorcycle through downtown in rush hour”. It’s not a suggestion, it’s a prescription. So get to it!
As always, the trick is to do “gem install rails” and then either changing config/environment.rb, if you’re bound to gems, or do “rake rails:freeze:gems” if you’re freezing gems in vendor.
UPDATE 2: We’ve fixed the zlib buffer problems for people on Windows. Redownload the gem and everything should be dandy.
UPDATE 3: Regarding security through obscurity, we’ll release the full details of this issue once everyone has had a fair chance to upgrade their system. Source transparency is of little comfort if you just had your system compromised before you got a chance to apply the patch.
UPDATE 4: This problem does not affect Rails 1.0 or earlier. The only versions affected are 1.1.0, 1.1.1, 1.1.2, and 1.1.4. See security update for details.
UPDATE 5: We’ve released Rails 1.1.6 with additional fixes to the problem and created backported patches for all affected versions.
P.S.: If you run a major Rails site and for some reason are completely unable to upgrade to 1.1.5, get in touch with the core team and we’ll try to work with you on a solution.
some svn trickery can nail down what the problem was pretty quick, I’m off to upgrade some installs now. I’d reccomend others follow David’s strong suggestions as well.
-mix
Does this security hole effect edge users below a certain revision number? If so, at which revision number was the fix commited? Feel free to email me the number please if the fix is meant to be obfuscated from hax0rs reading this blog. :)
“Edge from within the last couple of weeks” doesn’t have the issue. We’ll get more specific once people have had a chance to upgrade.
Anybody know what would cause the following message when running a “gem update”?
ERROR: While executing gem … (Zlib::BufError) buffer error
Maybe some tips for freezing rails in combination with subversion?
When I do rake rails:unfreeze subversion complains. And when I do svn remove vendor/rails rails complains when freezing.
security by obscurity? not really cool…
Nevermind. “gem install rubyzip” fixed it.
I seem to get some routing issues with standard routing on plugin controllers after upgrading to 1.1.5. I’m using Engines if that matters. Anyone else getting this?
Nate, how do we know you aren’t an elite haxor??? Must devise a test…
Point due east. Hmm… Okay, you seem legit, its release 9997.
So, uh, what’s the best way to get in contact with the core team?
I apologize for posting this issue as a blog comment, but trac is down, and you stress the importance of a 1.1.5 upgrade. “gem install rails—include-dependencies” returns “ERROR: while executing gem … (ZLib::BufError) after downloading actionpack apparently. This is on XP SP 2, ruby 1.8.4.
What exactly is the vulnerability and what is the impact (I would look at dev.rubyonrails.org but it is down with too much traffic). We are launching a very large rails site in one week and are currently locked at 1.1.2. It is going to be very difficult to convince management and the testing team to upgrade the production environment this late in the game. Has mongrel and all the rails engines been tested against 1.1.5? What about all the gems? These types of news releases really show the immaturity of rails.
Tim: A corrupted download, maybe?
I’ve blogged my rake rule for freezing to a specific version at http://blog.zenspider.com/archives/2006/08/upgrade_rails_n.html
It made upgrading (once it was tagged) a 1 minute process. It’d be nice if this could be incorporated in railties’s tasks.
Unfortunately, not for me. Still getting the Zlib::BufError error when trying to update Actionpack gem.
I’m getting the same error as Tim on Windows when attempting to update my Rails gem. A friend is experiencing the same thing on his Debian server. We both tried “gem install rubyzip,” as Tim suggested, but that didn’t help. (Between the two of us, we were able to successfully upgrade on OS X, FreeBSD, and Ubuntu.)
This is the error we’re seeing:
A rather humorous patch announcement you have here. Declaring an upgrade as mandatory without offering the public so much as a single glimpse as to what is wrong? You say the security hole is gaping… but you offer no proof of concept or exploit explanation.
No one should be expecting you to be posting pre-compiled code that script kiddies could utilize, but no one should be taking your concern for security seriously without a full disclosure of what is wrong.
Nate – What if you are a hax0r reading the blog!!! ;-)
You’ve got to be kidding. When has security through obscurity ever worked? We run quite a few semi-public (ie, heavy-use critical internal applications) here and we can’t afford to just upgrade without knowing what the problem is. Sure we could dig through changesets, and we probably will, but not fully disclosing a critical security problem is very bad practice.
You’ve got to be kidding. When has security through obscurity ever worked? We run quite a few semi-public (ie, heavy-use critical internal applications) here and we can’t afford to just upgrade without knowing what the problem is. Sure we could dig through changesets, and we probably will, but not fully disclosing a critical security problem is very bad practice.
Do we have to install this? I don’t want to if we don’t have to!
What about those of us who are using 1.0 cannot update to 1.1?
I’m getting the same error Tim was getting and installing rubyzip didn’t fix it. The upgrade went fine on RHEL 3 and is failing on Windows with that error.
We just upgraded zvents.com and I just wanted to confirm that the upgrade was smooth and painless for us. Previous releases have required some code changes, but this time all tests are passing and there have been no known side effects. Hope that gives others confidence to update their sites sooner rather than later.
As an aside, our site is a little slow right now due a packet loss issue in our data center. So, if you take a look, rest assured it has nothing to do with the 1.1.5 upgrade.
I’m still getting the buffer error. I wonder if it’s a Windows error only ‘cause I can totally update my *nix gems. :/
(Hopefully this won’t double post – the site is slow to respond.)
Unfortately, this doesn’t help me. I still get the buffer / Zlib error.
I’m having the zli::bugerror problem as well… any help?
Thanks guys. Looking forward to 1.2!
I get this error on Mac OS X : /usr/local/lib/ruby/1.8/rdoc/parsers/parse_rb.rb:539: [BUG] Segmentation fault ruby 1.8.4 (2005-12-24) [powerpc-darwin8.7.0]
Abort trap
I’m getting the same error (on Windows XP).
ERROR: While executing gem … (Zlib::BufError) buffer error
Installing rubyzip however did not fix it. Any ideas?
How does one go about upgrading the bundled copy of Rails that comes in the vendor/ directory of a pre-4.0 Typo install?
Not on XP
Microsoft Windows XP [Version 5.1.2600] (C) Copyright 1985-2001 Microsoft Corp.
C:\Documents and Settings\RDuzenbury.PANORA>gem install rubyzip Attempting local installation of ‘rubyzip’ Local gem file not found: rubyzip.gem Attempting remote installation of ‘rubyzip’ Successfully installed rubyzip-0.9.1
C:\Documents and Settings\RDuzenbury.PANORA>gem install rails—include-dependen cies Attempting local installation of ‘rails’ Local gem file not found: rails.gem Attempting remote installation of ‘rails’ ERROR: While executing gem … (Zlib::BufError) buffer error
Help!
Umm, won’t the diff between 1.1.5 and 1.1.4 give bad guys a pretty good lead on where to find the vulnerability anyway? It’s just the rest of us that are in the dark.
Dumb question, but ‘gem install rails’ is followed by ‘mongrel_rails cluster::restart’ in each and every Rails directory, right?
I am also getting the same error and installing rubyzip doesn’t seem to fix it.
Received the same buffer error. What is “rubyzip” and is that solution applicable to Windows also?
Tim, thanks for the tip, I was just going “What the heck!”.
I did
gem install rubyzip Bulk updating Gem source index for: http://gems.rubyforge.org Successfully installed rubyzip-0.9.1
and still getting the same error while updating gem actionpack
Thank you for the heads up!
That would be why there should be a 1.0 branch… apply the patch to 1.0 and call it 1.0.1 ; then 1.0 people could upgrade a simple bugfix without worrying about it breaking.
Rails core: you need to learn a few things about release management. :(
I was also getting the error:
I installing rubyzip doesn’t seem to have any effect. Doing a “gem update—system” got a few more gems to update, but then failed again.
Anyone know anything more? ( Using windows server 2003, against my will ;) )
I just happened to check my RSS feeds and caught this announcement.
But after this, I’m now looking for a security update only mailing list, and I’m not finding one. All I see off of the www.rubyonrails.org site is: http://lists.rubyonrails.org/mailman/listinfo/rails
Am I missing where it’s at?
I just want a low traffic mailing list that I can filter to alert me of updates and security updates ASAP. Both Debian and PHP offer lists like this.
Oops, actually the rubyzip does not help on Windows. I read packages would be updated to correct this, keep us posted.
Just to be nitpickingly clear, the stable branch at 4744 has the fix? I’m guessing it does based on the svn log, but based on the capital letterness here I want to be absolutely sure…
Laurel, correct. You can either bind to r4737 or you can use tags/rel_1-1-5.
DGM, we actually do have a tag for rel_1-1-0 and considering the fair number of people still tied to that, we’ll work on getting a fix ready for that version shortly as well.
Engines definitely seems to be broken. Others are having the same problem.
I’m in the same boat (almost) as Casey. We’re not launching a rails site, we’ve launched, and are way to busy to upgrade from 1.0 right now.
I’ve love a point release to 1.0 to fix this issue, or at least a “here’s how to fix it” posting.
Could you please include Ishikawa’s patch to ticket 3030 (IMHO also quite security-relevant) in one of the next security releases so that it needn’t be re-applied manually? See: http://dev.rubyonrails.org/ticket/3030
I was getting the Zlib::BufError as well on both linux and windows platforms (worked on mac), but it seems to be working fine now using the same command: gem update—include-dependencies
I second the points made by DGM and DW. I’m in the process of convincing my boss about using Rails for our next major project. I have had big hope in the success, but this makes me uncertain if that is a road I can recommend.
Don’t take me wrong – I appriciate your great work on the framework, but this kind of forced rushed upgrades could prevent me from the joy of using it for real work.
Thanks, DHH, I’m sure there’s a lot of 1.0 users that need the fix. :)
Bug fix point releases are fine with one line patches, if that’s all it takes to fix a bug. :)
I could see this happening again someday. Is there a security task force in the core team?
I realize sh*t happens, and the only thing you can do in such a situation is try to help everybody as best you can (which is what the rails team is doing).
So, thanks for letting us know and having a fix available so quickly.
A forced upgrade without explanation!? I’ll kill you DHH!
Hopefully nothing breaks during this upgrade. :)
I don’t think it’s so much security through obscurity as, “Update your systems now, we’ll explain it when folks are safe.”.
You can always look at the source changes if you’re curious.
Ivan Storck [#29]: I also have those errors. Seems to be unrelated to Rails (at least not to this release of Rails) but something in PPC Ruby.
I’ve Ruby 1.8.4 (2005-12-24) [powerpc-darwin] installed via Fink and have those errors installing via gems (and sometimes running Webrick). Just retry the command until you have no more errors.
Daniel, there’s no rush if you don’t mind having the security leak. Just as nobody is forcing you to upgrade Windows every week with the latest security fixes. Of course, not doing so greatly exposes you to the exploits of those holes. I think most people would appreciate the urgency and “rush” to get a fix out and applied in a hurry.
If you are aware of any other web platforms with major adoption that has never seen a security fix release, I’d love to hear about it. That must be a truly fantastic team that we’d love to learn from.
Winst, what would constitute a security task force in your mind? Every one in the core team cares about security (obviously, since we all have applications available over the internet). This hole was discovered within the core team and fixed by the core team. Does that qualify or are you thinking of something else?
Is the trac browser down on purpose to hide from malicious use—or just really slow because there are so many people trying to see the issue?
A quick glance at a diff between 1.1.4 and 1.1.5 showed a sql injection test case addition, but didn’t seem to have corresponding fix/changes.
Real work blabla bosses blabla this and that preventing blabla. Im all SICK of it. Quit your freaking jobs and start your own happy buissness! How can you whine about a new version? Specially when using rails! We should be the last guys on earth who would like to go back to the stone age. Im so fed up with people saying “you need to run apache 1 because its more stable” and stuff like that. Just be a part of developing the future or not. And thanks to david and the rest of the rails team for their excellent work.
It’s not the mere fact that there is a security release, it’s the fact that there’s a security release and you won’t tell us what it addresses, so we’re unable to make that decision about whether we should apply it or not.
Instead, we have to take your word that this is super-important.
Me, I’m happy with that, and in any case I can do a diff and see the magic secret. But you can see why people might be a bit frustrated with that approach.
DHH -
Daniel may be proposing a security “team” which is no more than those with the most security knowledge holding code reviews before any new code is released.
If that had been the case, we wouldn’t even be hearing about this issue, as it would have been fixed quitely, in-house, and without this headache (for yourself, and “us”).
seth, having security code reviews is a good idea. We’d love to see people looking at the Rails source code with their blackhat glasses on and supplying patches. If you know how, please do get started right away.
But its utterly unrealistic to think that it would mean absolutely safety from security issues. Windows, OS X, Apache, SQL Server, PHP, and just about any other piece of major platform software has had security issues even as millions (or in MS’ case, billions) of dollars has been spent on security reviews.
Daniel, take it from another Daniel. Opennes of security issues is key for enterprise software. DHH is open in the sense that he identifies the fact that there is an issue and even provides a fix for it, and the source code is just open and available. Many other companies that provide enterprise application servers are not so open nor so reactive to solve such an issue. As an enterprise architect I can only recommend for many reasons to use Ruby On Rails. This is however not the thread of this discussion, but one of my recommendation points is exactly the security that rails offers.
Has anyone figured out a way around the problem of engines being broken? I’m having the same issue.
DHH, can you re-confirm that the exploit affects 1.0? We’ve been able to replicate what I think is the problem on 1.1.4, but our production apps are 1.0 and we can’t upgrade.
We haven’t been able to replicate the problem in 1.0. Are there two separate problems? ie. should we continue trying?
This is why I don’t use computers. I never had ANY security holes on my pen and paper. Although I keep losing the papers on my desk.
We’ve got multiple sites on Rails 1.0, some of which will require serious hacking to upgrade (e.g., custom-patched older releases of Typo).
We need a 1.0.x gem, or else we’re hosed. There’s no way I can migrate all these sites to 1.1 quickly enough.
to Seth and everyone else who got headaches. Get som aspirin! You only got your self to blame because you didnt make maintainable applications in the first place! Some guys are complaining about their heavly modified typo application and stuff like that. And I just have to say, what did you guys think? Stick with rails 1.0 forever? If so, why even bother about a security issue? Dont build your applications on top of software you dont can maintain for example typo. All I had to do was to run gem update—include-dependencies and everything was updated, i barly had any problems with my applications, everything was easy to fix. Why? I just think its a matter of planning the software. Maybe David who is expert in this can tell us more about how important this is.
Nothing is abnormal about a framework this large having a vulnerability from time to time. But corporations cannot make decisions for deployment based on the (lack of) information provided in this announcement. We love the rails environment and have been pleased with most aspects of the software delivery. However, when the rubber hits the road (real world security), procedures have been Horrible. Partial disclosure doesn’t give those who are running applications enough information to come up with a workaround (like using a webserver filter language to disallow the malformed request) and certainly not enough ammunition to convince a Suit that an immediate software upgrade is necessary. This leaves only the blackhat community free to play with the tree at their leisure, knowing that without drop-in patches for old versions or siginificant disclosure to upgrade the situation to Critical in an Enterprise environment, they’ll be able to run their sploit (which took 10 minutes to build) for weeks or months to come. Not maintaining an informative, coherent policy and procedure for releasing these announcements and patches could not only keep rails from being adopted in such managed environments, but flat-out get it pulled and replaced in those which it has already found its way. Including mine.
Security through obscurity is no security at all. A cracker can SVN diff it and have an exploit packaged up in under an hour. Once that hits the net, thousands of script kiddies will have it. Not disclosing the vulnerability doesn’t affect them; it only affects the legitimate user community. How can we know if our systems have been compromised when we don’t even know what sort of compromise to look for?
How do you contact the core team? I’ve got a large project on 1.0 that will need some substantial changes to update (and I’m not actually responsible for it anymore, but I’d like to work out something).
How difficult would it be to release a patch?
Good point – what about the multitude of Typo installations frozen to Rails 1.0? The last thing you want is a whole bunch of Rails powered blogs being knocked out of service.
Oh, and cheers for the heads up :) Even though updating one of our projects to 1.1.5 from 1.0 will be a small undertaking it wont be a big bad deal.
It means we’ll have to move our extentions out from ‘hacking rails code’ to proper plugins, which we know how to do, now :)
Thanks for the heads up. Upgrade is complete here.
I see a lot of posters here think the way the vulnerability is being handled is careless and unhelpful.
In regards to bougyman’s post, it sounds like he’s running with iron shoes. Your employer (company, whatever) adopted an agile framework, but (per your description) doesn’t have the social agility to handle unexpected surprises. Interesting. :)
In regards to John’s post about doing an SVN diff – it sounds like you already know how to zero in on what the patch fixes. Why don’t you do that? :) (And then share it with us.)
Maybe DHH gives people a little too much credit. =P
That said, “at least we know.”
If we are on shared host without permission to update required rake dependency, will:
svn export http://dev.rubyonrails.org/svn/rails/tags/rel_1-1-5 vendor/rails—force
executed from the home directory for the application cover us?
OK, after closely examining the patch, verifying an attack against 1.1.4, failing to verify the attack against 1.0, and carefully reading through the corresponding code in 1.0, I’m not seeing any evidence that 1.0 is affected.
A request to people on the inside: Please either verify that 1.0 is safe, or release a patch for 1.0.
Failing that, please confirm that Rails 1.0 is officially unsupported, and all production systems still on Rails 1.0 need to be ported to 1.1 immediately.
Mark: I’d imagine this is extra incentive for all those ppl to get their typo blogs up to 4.0. Those older versions of typo weren’t exactly stable, anyways, with the memory leaks and what not.
Is this patch related to fragment caching? One thing I just noticed is that its creating random folders in my cache directory for sites i dont own like babel.altavista.com, myweb.yahoo.com among others. I assume their is a flaw here cause there must be a way for an outside user to write any number of directories in my cache dir.
I’ve upgraded rails under Linux without any errors, thank you for your effort!
I figured out how to fix Engines, but explaining it would give away the exploit. It is very, very severe. If you use Engines you might want to drop back to 1.1.3 which evidently is unaffected.
“Good news: Rails 1.0 and prior is not affected”
Those on shared hosts running Ruby 1.8.2 breathe a collective sigh of relief…
It’s been said several times already, but needs repeating: Obscurity does not help or protect us.
As a fairly fresh newcomer to Rails, I love my experience with RoR so far, but your security release policy shows a an immature understanding of addressing security issues. Please look to the example of more mature infrastructure projects for examples of the right way to manage this.
Once you’ve said anything in public and released diff-able code, you absolutely are not hiding the vulnberability from the bad guys. But by not offering patches to all the in-use release levels and refusing to discuss the nature of the vulnerability, you are extending the vulnerability windows for many Rails apps.
You could and should be engaged in a collaborative effort with your user community to test and improve the security patches, not playing hide the pickle with crackers who you should assume are already dishing out the relish.
see more info about this at http://blog.evanweaver.com/articles/2006/08/10/explanation-of-the-rails-security-vulnerability-in-1-1-4-others
DHH > In response to #57.
What I meant by “forced rushed upgrades” would be the need for upgrading not only with a security patch, but from an enviroment running stable on 1.0 directly to 1.1.5 with possibility of breaking the application.
In your example that’s like Microsoft no longer supporting Windows 95/98 with security patches – and that’s the actual case, but they notified that a long way before, hence no “rush”.
Now it seems like 1.0-users aren’t affected, and that’s great. But I still would need/like to know that future patches will be available for the branch we eventually will run our applications on.
What I seconded was the idea of a security issue announce mailing list, and some kind of statement on wich branches are officially supported with new security patches.
Sorry if I upset you. I tried to express my concerns without sounding like whining, but I possibly failed.
So do you have to change this line in environment.rb as well?
RAILS_GEM_VERSION = ‘1.1.4’
The backlash of this security update was interesting.
I don’t think the core team handled it that bad. They already had a fix ready upon announcement.
True that it doesn’t make sense to hide the specifics when a quick diff of 1.1.5 and the previous version reveals where the hole was.
Also the ignorant misuse of “security by obscurity” is laughable because it refers to secrecy of design, implementation, etc. which is obviously impossible in an opensource project.
What we are talking about are transparency issues here.
With more and more high traffic sites using rails, my suggestion is that in the future if and when a security leak is discovered, the rails team provides a contact point where companies affected can get the specifics of the vulnerability.
This should satisfy transparency concerns until ample time is given for an upgrade.
I feel bad for the core team because here they are halting everything to get a security patch out and handling the issue in a remarkable manner in most respects and suddenly everybody thinks the project is being mismanaged or that they are spitting in the face of all rails developers.
Plus, what if DHH just said, “1.1.5 is just some bug fixes and other issues—highly recommended for users of 1.1.x on”?
That would be “security by deception”. The need for better transparency in handling this may be a valid concern but we need to look at it calmly and have a constructive dialogue instead of a knee jerk reaction.
However, I will say that having the Trac down at a time like this sucks major and only exacerbates the problem. That’s the interface for most of the community to the source code and it should never be down no matter what the reason.
I updated about 8 different apps and I didn’t have to shed 1 tear.
Thanks for the heads up.
Joel, could you email me a solution (marcus (at) vorwaller (dot) net) because in the meantime my site is down because of the engines issue. If you email me I’ll show you the site etc. to show that I’m not a l33t h4×04 :)
Sheldon Kotyk: “This is why I don’t use computers. I never had ANY security holes on my pen and paper. Although I keep losing the papers on my desk.”
You’re not losing them. That’s the 1337 kL33n0rZ stealing them!
This is the first time I’ve upgraded. Is ’ gem install rails—include-dependencies’ all that is necessary? Or is there more that I need to do? I didn’t encounter the Zlib error that others have.
People who bleat “security through obscurity never works” don’t know what they’re talking about. Security through obscurity has worked
lotsof times.There are also times that it hasn’t.
If you want to dictate how an open-source platform distributes its updates, then start one yourself. Their project, their call.
http://www.lippert-at.com/index.php?id=315
DHH: Qmail is a major piece of software without any major security flaws.
I want to give my verbal support to the rails core team. I believe it would have been better to disclose more info about the bug but comparing all the pros and all the cons that rails has given me and taking into account that ruby and rails are FREE software that I did not pay a dime to use I can’t imagine me bashing you for the way you are handling this (what I see is that you are honestly attempting to minimize the damage).
While so many are complaining (b#tching as far as I’m concerned) about being locked into ver x.x.x, is that not the whole reason to write unit, functional, and integration testing? Upgrade on a test machine and run your tests, if you haven’t written tests then you have no right to complain as far as I am concerned. And if you have no clue as to how to write the tests properly then you probably have more to worry about in your application deployment then a critcal flaw in rails. No time to write tests well that’s like saying I have no time to work with version control, it’s an excuse and nothing more.
Is it required to run rake rails:update after doing this?
How about posting on bugtraq like nice normal people do when there’s a security vulnerability? It helps those of us for whom rails is just one in thousands of installations of various packages.
Thanks for all your great work, Rails team! I think your temporary “security through obscurity” approach is the best that you could have done, given the circumstances.
Guh! So a post appears on a site saying there’s a serious security flaw in the software running that same site.
Then you’re urged to download and patch immediately from that same possibly compromised site and server.
Who’d do that ?
Ever ?
Fix for Engines: http://dev.rails-engines.org/repository/changesets/414
Although I also am an advocate of full disclosure and public SA papers, what appears to be problematic is the lack of support for older branches.
A “Security officer” team’s task usually encompass patching older supported trees.
Often, one to two older releases will continue to be supported and security patches always applied to those branches for those who track the branch sticky tag. Too old branches eventually get deprecated and stop being updated of course, but this is part of the well known policies of the project and there never are surprises.
This, of course assumes that users and developers both know how to properly use their software versioning system.
This method has worked for many projects for many years and has proven successful (including for substantially larger projects such as the BSDs). There probably is some learning to do here by the development team.
Thanks
Gotta love the knee-jerk buzzword-parrotting responses ;D
DHH -
Can you tell us when you’ll release full disclosure? How long are you going to give people. All I’ve seen to date is a “fair chance”.
Thanks, -philip
Just update our server, btw to some of you, Arnie says: “STOP WHINING!”
I just wonder what’s going on here. Some people say it’s fixed, but my apps still break with Mongrel and so I had to patch routing.rb line 276 with this
base.match(/\A#{Regexp.escape(extended_root)}\/*(?:#{file_kinds(:lib) *’|’})/) || base =~%r{rails-[\d.]+/builtin}
before it would work with Mongrel.
Thanks to Sander Land from the Rails list for that, or I’d be down right now.
It doesn’t appear to be fixed everywhere… so I’d like to know why I’m rushing to patch things.
I appreciate the core team’s commonsense approach to this situation. Upgrade went smoothly for me. Thanks.
Not disclosing the nature of the issue is baaaaaaaaaad. -5 for handling.
Bad timing—sometime this morning between the different machines I had to upgrade, it appears that Rails 1.1.6 has been released which has a dependency on a version of actionpack that doesn’t actually seem to exist. Thus it breaks a blind attempt at “gem update rails” which doesn’t go into specifics as to why actionpack cannot be installed. For those that run into this problem, try “gem install rails -v 1.1.5”
What bothers me the most about this is that I believe I’ve found some bugs in the patch, as have others. I respect the team’s wish to try to keep this under wraps, but the infrastructure for discussing problems with the 1.1.5 fix without making it fully public does not seem to be in place. I sent my findings to DHH, but was unable to locate the email address of the author of the original fix. If delayed disclosure is going to be used going forward, some form of infrastructure and instructions for communicating problems with the “fix” to the core team needs to be developed and made easy to find.
Paul, that was slow gem propagation. This has been fixed. We also reported an alternative way to do the update in the Rails 1.1.6 announcement.
Ok updating now.
But not releasing any info about the problem doesn’t seem like an professional way to handle the problem.
Who knows you are not someone who has hacked the site and has somehow injected your own hacked version of rails in the gem install system?
WOW.
The response and attitude of the Rails team towards this security issue must be the best I’ve ever seen in a similar situation.
Way to go.
Engines are still not working… the path suggested by Pascal does not work…
...any ideas?
Hi. Why no details are released? What if I can’t patch? Could I twart or stop an attack using a firewall rule or container configuration? What If I use a layered security model (Firewall/IDS/OS Hardening/Container Hardening/App Hardening)? See that’s why security through obscurity does not work, even if you give a fair chance to upgrade, someone will not be able to upgrade in time. It is faster to come with a firewall rule or another workaround and patch at your own time. Ever heard about zero-patch sercurity? You guys know ANYTHING about patch managemen or information SECURITY to say the least?
All you are saying is… if you are a bad guy with time in your hands, diff 1.5 against a vulnerable version and comeup with your attack. If you are a sysadmin with no time to spare… you are on your own.
Redeem yourselves and give at least some alternatives to the patch.
Cheers
Given today 1.1.6 post i’d like to compliment the RAILS team. Great work, courageous tactic.
Not revealing the actual patch. Does that mean that you havent fixed the complete security hole. Maybe you have patched only part of it and therefore fear that someone may realize the rest of the gaping hole? That definitely sends jitters up my spine on the stability. How many more such black box patches will I have to install on my site going ahead?
Ash: Please see the 1.1.6 post. Patches are available for all affected versions.
rubyzip is not used by rubygems, so installing it or updating it will not solve the Zlib::BufError you see when attempting to install the rails gem. Both rubyzip and rubygems rely on zlib, and both occassionally run into the Zlib::BufError. I believe it is a bug in the ruby-wrapper of the zlib library.
Hi, I’m a total ruby/rails novice and have just been given a rails site to support. I’m running rails 1.1.2, but it’s not entirely clear what I need to do to update it. Are there any step by step instructions on what I need to do? thanks