13 ms·
Multiple vulnerabilities in parameter parsing in Action Pack
- steveklabnik 14y agoTo emphasize: > Due to the critical nature of this vulnerability, and the fact that portions > of it have been disclosed publicly, all users running an affected release > should either upgrade or use one of the work arounds *immediately*.
- tptacek 14y agoPatch right now.
- vinhboy 14y agoSomeone should change the title of this post. I didn't read it for a good 3 hours because I didn't realize it was related to Rails.
- judofyr 14y agoThis is bad, bad, bad, bad! SQL injections, remote code execution, DoS. Pretty much everything is possible with this exploit. You don't even need the secret key which was required in the previous vulnerability. Upgrade NOW.
- danso 14y agoBefore anyone wonders if they're having deja vu, this is different than the SQL injection vulnerability that was discussed 5 days ago: http://news.ycombinator.com/item?id=4999406 http://news.ycombinator.com/item?id=4999406
- tptacek 14y agoThis isn't a SQL injection vulnerability at all.
- danso 14y agoAre you referring to the OP? The OP states: > There are multiple weaknesses in the parameter parsing code for Ruby on Rails which allows attackers to bypass authentication systems, inject arbitrary SQL, inject and execute arbitrary code, or perform a DoS attack on a Rails application. This vulnerability has been assigned the CVE identifier CVE-2013-0156.
- tptacek 14y agoI'm stating direct knowledge of the vulnerability. It's worse than SQL injection.
- joevandyk 14y agoBut you can use this to trigger the earlier SQL injection vulnerabilities, right?
- batgaijin 14y agoAt least people are getting practice at following security bulletins.
- benmmurphy 14y agoAn attacker can execute any ruby code he wants including system("unix command"). This effects any rails version for the last 6 years. I've written POCs for Rails 3.x and Rails 2.x on Ruby 1.9.3, Ruby 1.9.2 and Ruby 1.8.7 and there is no reason to believe this wouldn't work on any Ruby/Rails combination since when the bug has been introduced. The exploit does not depend on code the user has written and will work with a new rails application without any controllers. Here is the commit where it was introduced: https://github.com/rails/rails/commit/27ba5edef1c4264a8d1c0e54675723d37a391dd8#L5R133 https://github.com/rails/rails/commit/27ba5edef1c4264a8d1c0e...
- tptacek 14y agoI can confirm most of what Ben says directly. What I can't confirm, I can't confirm only because Ben is smarter than me about this stuff.
- jerf 14y agoI don't speak Ruby. Can you or someone else be more precise about where that introduces the vulnerability? (Surely it isn't that YAML::load(content) can run arbitrary shell code?)
- tptacek 14y agoCalling YAML::load on attacker-controlled content in a Ruby app of any complexity is very bad news. As Ben and 'judofyr said: this is remote code execution.
- aaronblohowiak 14y agoIs this because Yaml doesn't whitelist the classes for the objects that may be instantiated? They are allocated and then instance_variable_set'd so I'd be Very interested to learn how this poses a risk.
- tptacek 14y agoThe people saying that they have POC code for remote code exec aren't making it up.
- 10char 14y agoCorrect me if I'm wrong, but looks like this should only be a vulnerability if your app uses XML parameters?
- sergiotapia 14y agoAs a newcomer to the Rails ecosystem all these posts of vunlerabilities and open doors leaves a bad taste in my mouth. God know I love programming in Ruby now, but is Rails really that insecure?
- robconery 14y agoAll web frameworks have vulnerabilities - the key is how quickly the team responds. For that, I love Rails (and @tenderlove)
- sergiotapia 14y agoI agree completely, it's just that this error seems so obvious and dangerous that it's odd it hasn't been caught for over 7 years. ps: I love Tekpub! Are there any plans for some new Rails videos? I purchased the Rails 3 series but it's a bit outdated, given how fast Rails moves. Would purchase a series on Rails 4 day-one. :)
- phillmv 14y agoSecurity is a process; what matters is how people respond to new vulnerabilities. I'm naturally biased pro-Rails, but so far I don't feel uncomfortable with how it has been handled. I can't comment on how on-the-ball the Rails security team is, but I can say it's really easy to update your apps. It's also relative to your alternatives. It's way safer than not using a framework. Is it safer than Django? That's kind of unknowable; maybe, maybe not.
- benmmurphy 14y agoI've worked with other vendors. The rails security team is the best I've worked with. The major positives: * Quick turn around. I have another vendor where it takes up to 3 months to get stuff fixed. :( * They give you a patch to review before releasing publicly. This is very important and gives researchers a chance to fix any problems with the patch. With another vendor their fix missed a really obvious attack vector and anyone who diffed the code would have been given a free zero day vulnerability. :(
- tenderlove 14y agoI'm just commenting here so that people can have a central thread for love / hatred. ;-) But seriously. This is extremely critical, please upgrade!
- fromonesrc 14y agolove++
- djbender 14y agolove += 1
- diminish 14y ago3 links on HN frontpage for this same vulnerability proves the love of the community to warn each other tenderly.
- danso 14y agoThere's actually two vulnerability announcements: https://groups.google.com/forum/?fromgroups=#!topic/rubyonrails-security/t1WFuuQyavI https://groups.google.com/forum/?fromgroups=#!topic/rubyonra... This one deals with problematic JSON parsing and affects only 3.x. It is dealt with in the release that fixes the other vulnerability
- 13k 14y ago<3++
- tyre 14y agoThanks for your awesome work and continued vigilance Aaron!
- joevandyk 14y agoThese are the commits that need to be pulled in, right? https://github.com/rails/rails/commit/d5cd97baa44fa66dc681041a213092b45c57c32f https://github.com/rails/rails/commit/d5cd97baa44fa66dc68104... https://github.com/rails/rails/commit/43109ecb986470ef023a7e91beb9812718f000fe https://github.com/rails/rails/commit/43109ecb986470ef023a7e... Are there others?
- benmmurphy 14y agoThis vulnerability is also present in other other Ruby libraries. I would advise anyone to do bundle install --deployment in there development environment then 'grep -r "YAML::load"' and 'grep -r "YAML.load"' in the vendor/bundle directory. If you have YAML::load(user_controlled_value) or YAML.load(user_controlled_value) then you might be vulnerable to remote code execution. There are some other ruby libraries that are vulnerable to this attack but I don't want to post about them until their authors have fixed them.
- zwily 14y agoGood reminder, but this has always been true. Giving unfiltered user-specified content to YAML has never been a good idea.
- the1 14y agoruby on cracks
- sdoowpilihp 14y agoCan anyone with a more intimate knowledge of the inner workings of Ruby on Rails speak to how detrimental this exploit is in practice? I seem to recall a fair number of people feeling the SQL injection exploit from a few days ago was being blown out of proportion and I was wondering how this particular exploit stacks up against it.
- tptacek 14y agoThis one is not blown out of proportion. Lots of people have working proof-of-concept exploits for this. The vulnerability has no app dependencies. You don't need a session secret. You don't need a login. There are vectors for the vulnerability that will work against applications that don't even have exposed controllers.
- danso 14y agoI'm not going to say "told you so" because I said nothing and I'm just a layman in this...but when people were pointing out last week that the bug was "overblown" I had wondered if they were underestimating the tendency for such vulnerable patterns to propagate. The mechanisms that let even an edge case in are not always isolated.
- martinced 14y agoOh I'm saying "told you so". Since years and years. The real problem is the very mentality of the people who downplay security issues, always saying "this is not a serious issue" (or, worse, saying "but language xxx / framework yyy" suffers from issues too, it's how the world works). That mentality is the reason why such exploits do exist in the first place. Security is nearly always an afterthought. The most braindead argument being: "My goal is to sell xxx, not to have an unbreakable server". Once you read that one, you know you have reached the low of the low.
- FooBarWidget 14y agoOr maybe some issues are overblown, while others are not. Also, the message was not "overblown". It was "don't panic, but still upgrade ASAP".
- viseztrance 14y agoI really don't understand the last part "This vulnerability was reported to us by numerous people, many thanks to [...]". Considering it affects all versions, what are the odds of multiple people pointing this out at the same time? Rails has a very good track record regarding these things, but I'm just curious.
- steveklabnik 14y ago> Considering it affects all versions, what are the odds of multiple people pointing this out at the same time? My understanding is that while investigating the SQL issue a week or so back, it gave several people ideas on how to make this exploit happen, and they all reported it.
- tptacek 14y agoThe last Rails SQLI vulnerability was mitigated by the way ActionPack parsed request parameters, so lots of people dove into that code to see if the mitigation could be evaded with JSON or XML. That gave people incentive to review Rails XML parser wrapper class. The problem with that class is pretty obvious.
- viseztrance 14y agoMakes perfect sense. Thanks for pointing this out.
- ceejayoz 14y agoI'd guess multiple people working together, or multiple people who got hit by someone exploiting it in the wild.
- tptacek 14y agoNo, it was discovered by multiple teams independently, and not from exploitation in the wild.
- benmmurphy 14y agoYou could also deduce from the previous vulnerability disclosure or comments from rails developers who knew about the vulnerability that there was a way of generating symbols. This is how I found it. But there is still a big step from knowing about loading YAML to creating an exploit.
- fwilhelm 14y agoFor those of you interested in more details about this bug: I've posted a first analysis at http://www.insinuator.net/2013/01/rails-yaml/ http://www.insinuator.net/2013/01/rails-yaml/
- steveklabnik 14y agoI don't think this is very responsible of you. You should post this, but you should really wait a week or so.
- davesims 14y agoAgreed.
- marshray 14y agoAccording to tptacek, "it was discovered by multiple teams independently" and "Lots of people have working proof-of-concept exploits for this". I think your week started Jan 02 with CVE-2012-5664.
- steveklabnik 14y agoBut it was not knowledge to the general public until today. That's what matters. Those people have POCs, but they're not spreading them.
- marshray 14y agoOne should never assume that he has a handle on everyone who knows the existence of a bug. I think you underestimate your adversary. https://twitter.com/mikko/status/288766998228393984 https://twitter.com/mikko/status/288766998228393984
- steveklabnik 14y agoYou completely mis-understand my point. I don't think that this is the only person who knows this, that'd be idiotic. They are, however, the only person who posted it in this thread. Giving it more publicity. I don't think that that extra publicity is appropriate.
- sproketboy 14y agoWho still uses this crap?
- rschmitty 14y agoRails noob here... with this and the other vulnerability from a few days ago, do all you need to do is update your rails gem to become safe? Current version at time of my post is 3.2.11, if I'm using that am I safe or do I need to perform additional steps?
- blacktulip 14y agoif you have any production using rails version < 3.2.11 then upgrade to 3.2.11. You should not have to do anything else than upgrading.
- senorprogrammer 14y agoThat's exactly what you need to do. You're safe.
- cschneid 14y agoThat is correct. The latest 3.1.10, or latest 3.2 series have this update. See the top of the linked notice: Versions Affected: ALL versions Not affected: NONE Fixed Versions: 3.2.11, 3.1.10, 3.0.19, 2.3.15
- Argorak 14y agoThis hits one my basic complaints about Rails: it activates too many features _by default_. Even if your app does not parse XML params, the parser is active. I know its convenient, but hey - is this worth the price of exposing _everyone_?
- tptacek 14y agoThat's not a fair critique here. The problem isn't that Rails exposes XML by default. Everyone knew it did, and just processing XML isn't the issue. The problem is that the XML code used in the untrusted request path was also used by code that handled trusted messages elsewhere, and those trusted messages had requirements that weren't appropriate for request-path messages. Because JSON is so much more popular than XML in Rails apps now, a reasonable workaround for this problem is to just turn off XML if you're not using it. More importantly, it's a workaround that (a) does more to reduce the attack surface given how XmlMini works, and (b) was a workaround that disclosed less of the vulnerability last week. But don't let that confuse you about the nature of this bug.
- Argorak 14y agoYes, it is a valid critique. You are right that just deactivating XML parsing is a reasonable workaround - and in my opinion so reasonable that it should never be activated by default in the first place. A lot of people get bitten by a component they never consciously used and activated in the first place. While the second part is true for almost every part of a framework, the first one is problematic. ("XML? Why do I have a vulnerability through XML and YAML in a JSON-only app?")
- FooBarWidget 14y agoI'm the author of the "Rails SQL injection vulnerability: here are the facts" blog post last week. This vulnerability is a different and unrelated one, and is very serious. Upgrade immediately.
- clickonchris 14y agoUpgrade instructions: update your Gemfile and set the version you want. In my case: gem 'rails', '3.2.10' locally, run 'bundle update rails' which will update your Gemfile.lock check-in and deploy your code. If you are using capistranso, the default 'deploy' task should handle everything for you. Otherwise, run 'bundle update rails' on your production server.
- tptacek 14y agoThe advisory also provides several workarounds that dont' require you to update Rails, all pretty simple ("drop a file into config/initializers and reload) which also work.
- nathan_f77 14y agoYou need rails 3.2.11, which has the patch.
- boundlessdreamz 14y agoThe fixed version is 3.2.11
- deleted 14y ago[deleted]
- jrochkind1 14y ago3.2.11 not 3.2.10. Which is in fact why it's probably wiser to list `gem 'rails', '~> 3.2.10'` (or 3.2.0 or anything) instead, and then `bundle update rials` will update you to latest 3.2.x (but never 3.3.x), in this case 3.2.11, instead of only to the exact version you specified (3.2.10, incorrectly).
- clickonchris 14y agowhoops. sorry about that typo
- moe 14y agoI hope in consequence of this incident the Rails-team will build in an automatic security-update notification mechanism. I'd like my apps to poll rails.org (or whatever) every few minutes and by default shutdown hard when an incident like this is announced.
- davidw 14y agoYou can set up a system like Debian or Ubuntu to automatically install security updates.
- moe 14y agoI want my rails instances to shutdown within minutes of an announcement, not hours or days.
- xnxn 14y agoHeadline of the future: > Tens of Thousands of Rails Applications Remotely Disabled Following Rails.org Intrusion
- moe 14y agoYes, that is to be expected - and absolutely worth it. The aftermath of an incident like the current one is a lot more expensive than an unplanned downtime.
- xnxn 14y agoJust playing devil's advocate here: a truly evil attacker could use the access logs from all the apps phoning home to build a list of vulnerable targets! :)
- moe 14y agoWell, you are right, the idea wasn't thought out very well. I was in a bit of a bad mood during patching up various rails deployments around here... However, perhaps they could just promise to post a signed message, in a specified format, on a dedicated twitter account, if such a thing happens again. This would seem like a relatively low-tech approach, about adequate for such a rare event (just keep that secret key secret!). The community can then roll their own gems to watch said twitter-account and act according to any user preference. Perhaps one of these gems would even make it into rails-core after sufficient review. Obviously one can always argue whether such a rare case deserves dedicated infrastructure. But on the other hand we have yet to see how many rails deployments will be bitten by this incident in the long term. It's not uncommon to see years of exploitation for a vulnerability in a popular piece of server software.
- jacobn 14y agoSo I've applied the workaround, which is great, but how do I test that the workaround is indeed working? I realize that providing an in-depth answer is tantamount to publishing an exploit how-to, but some reasonable way to privately test this would be very useful. Maybe a "simple" URL tester hosted by a trusted Rails source (e.g. rubyonrails.org)? Ok, has the obvious issue of showing the world who they should target, but maybe you can riff on that theme? Auditing and stuff you know. For some reason people in charge get really upset when all our base are belong to the bad guys.
- espes 14y agohttps://github.com/rails/rails/commit/46e0d2397ea10a0bf380926c9fe3cfcf14d5c499#L0R119 https://github.com/rails/rails/commit/46e0d2397ea10a0bf38092...
- jrochkind1 14y agoHmm, this may explain why the vulnerability patched in 3.2.10 was more dangerous than it seemed, eh? The 3.2.10 announcement provided an example of `Model.find_by_id(params[:id])` as an exploit, but nobody could figure out how you could get a hash with a _symbol_ key into `params[:id]`, which is what it would take for that to be an exploit. So people were confused. But the pre-3.2.11 exploit, apparently, possibly provides ways to do just that, eh?
- jgeralnik 14y agoThat's how this vulnerability came to light. After finding out about the last vulnerability, there was a huge amount of interest in seeing if parameters could be exploited, leading to a number of people simultaneously discovering this flaw.
- xentronium 14y agohttp://www.insinuator.net/2013/01/rails-yaml/ http://www.insinuator.net/2013/01/rails-yaml/ Some explanation why YAML user input is evil. It works like this 1.9.3p327 :001 > id = YAML.load("--- !ruby/string:Arel::Nodes::SqlLiteral \"1 --\"\n") # if user input can contain arbitrary YAML "1 --" It looks like string, but it's not. 1.9.3p327 :002 > Keyword.where(:id => id).first Keyword Load (0.3ms) SELECT `keywords`.* FROM `keywords` WHERE `keywords`.`id` = 1 -- LIMIT 1
- charliesome 14y agoPosting the gory details this early on is not a nice thing to do. It's probably best to hold off for a while until everyone has had a reasonable chance to upgrade.
- merlincorey 14y agoDo you think not selling guns on an open market stops criminals from obtaining them as well?
- charliesome 14y agoIf you want to get into silly analogies, compare the US to Australia. Tight firearms restrictions in AU makes it significantly harder for criminals to obtain guns.
- tptacek 14y agoIf anybody thinks we're solving vulnerability full disclosure once and for all on an HN thread about a Rails vulnerability, that person is pretty naive. We've now officially captured both sides of the argument and can safely move on.
- elliotanderson 14y agoAt this stage with the vulnerability publicly and widely reported - demonstrating an attack vector that involves seemingly harmless code is perfectly acceptable. Not everyone understands the magic involved and it would be able to spot exploitable code.
- caseyf 14y agoI was curious about why Rails parses YAML nested inside XML to begin with. Turns out it was put in way back when so that ActiveRecord's from_xml/to_xml work as expected when a model contains serialized (ie. yaml) attributes. Patch/issue from the old Rails issue tracker: http://web.archive.org/web/20071218105822/http://dev.rubyonrails.org/ticket/7502 http://web.archive.org/web/20071218105822/http://dev.rubyonr...
- fernandezpablo 14y ago1. Keep this link bookmarked. 2. Pull it off next time someone starts with the 'test-replace-static-typing' argument. 3. WIN
- prodigal_erik 14y agoThis problem is due to deserialization creating object (sub)graphs which are unintentionally too powerful. Statically typed languages (especially without dependent types) can do this too, even when the root object(s) matches the type(s) expected by the caller. The cure is http://en.wikipedia.org/wiki/Capability-based_security http://en.wikipedia.org/wiki/Capability-based_security: write out what the caller is currently allowed to do, rather than blindly granting dangerous privileges and relying on the code's design never to use them. Even tainting, a very crude manual form, seems like it could have caught this.
- simonw 14y agoStruts2 had a similar vulnerability last year: http://websec.wordpress.com/2012/01/04/multiple-vulnerabilities-in-apache-struts2-and-property-oriented-programming-with-java/ http://websec.wordpress.com/2012/01/04/multiple-vulnerabilit...
- willvarfar 14y agoWhy doesn't Ruby (and Python and all other languages) have Perl's tainting built in and always running? I'm not advocating it as the only security mechanism, but rather as another barrier to be overcome just like address-space-randomisation, data-exection prevention and all the rest... (Haven't Google recently shared a valgrind-lite runtime bounds checker which is being incorporated into GCC etc? Might lead the way on how this can be down with the minimum of runtime cost.)
- headius 14y agoBecause tainting is an inherently flawed way to do security. Blacklisting capabilities/methods/data always leaves holes behind, and it's nearly impossible to secure a system using tainting alone. Even the Perl folks say it shouldn't be used as a security mechanism...it should be used to help thin out security issues during development and testing. If you want to secure a system...whitelist, don't blacklist.
- teyc 14y agoIf the runtime overhead is low, then shouldn't tainting be used in addition to other techniques? ala Defense in depth?
- headius 14y agoYou certainly can do that. You can also add more and more locks to your doors while leaving your windows open.
- mpyne 14y agoMy understanding of the taint flag as implemented in Perl is that it is very much a whitelist. All user input is born tainted and much be verified clean before the flag is removed. It's possible to screw this up by verifying too much, but that's an overly-expansive whitelist problem, not a blacklist that isn't restrictive enough.
- Argorak 14y agoMRI has tainting through SAFE, but its generally considered problematic and might give a false sense of security. MRI and Rubinius don't implement it.
- amalag 14y agoFor a less hammered server, can use: source 'http://bundler-api.herokuapp.com http://bundler-api.herokuapp.com in your Gemfile
- 1qaz2wsx3edc 14y agoGems are unsigned. Patching from a different source is idiotic. Do not use: you have no clue who is the owner.
- amalag 14y agoNot so idiotic if you know the owner. It is done by Heroku's Ruby team http://hone.heroku.com/bundler%20heroku/2012/10/22/rubygems-and-the-dependency-api.html http://hone.heroku.com/bundler%20heroku/2012/10/22/rubygems-...
- Kafka 14y agoI might be the last one on earth that still runs a Rails 1.1.x app. This time the ancient one dodged a bullet. "ah, actually 1.1.x isn't vulnerable. The issue first arrived in 2.0" - https://twitter.com/tenderlove/status/288777229276704768 https://twitter.com/tenderlove/status/288777229276704768
- benmmurphy 14y agowe had some rails 1.x apps at work and we were happy.
- benmmurphy 14y agoif you are using extlib gem you may be vulnerable as well. it has just been updated: https://github.com/datamapper/extlib/commit/633974b2759d9b924657f3888473d5fd681538dd https://github.com/datamapper/extlib/commit/633974b2759d9b92...
- callmevlad 14y agoGithub.com (built on Rails) is currently having issues. If I had a tin foil hat, I'd put it on. Hopefully their issues are not related to this vulnerability.
- senorprogrammer 14y agoMore likely the result of millions of Rails site owners crying out in terror... pulling and then committing updates. I fear something terrible has happened.
- tubbo 14y agoGood thing you don't have a tin foil hat, because you are way too stupid to own one responsibly.
- holman 14y agoWe had a database spike in load. Nothing Rails-related.
- amix 14y agoI am shocked that it's considered a smart idea to make it possible to execute code from XML files (and that this is the default setting)!?
- jgeralnik 14y agoOf course it's not considered a smart idea. That's why this was fixed. It was a (critical) bug.
- teyc 14y agoI don't use Rails, and read up on the vulnerabilities. Here's a quick summary: 1. This class of problems is not unique to Ruby. 2. Similar problems have been identified in Struts, and python's pickle. 3. Specifically in this case, YAML.load() can deserialize unintended object types. In the case of Struts the problem was the expression library used can also deserialize unintended object types (like File), plus setting properties on these types can have side effects (such as dropping files into your system). 4. I took a look at Microsoft's WCF. The DataContractSerializer states that it only is allowed to load types that are specified by a contract. http://msdn.microsoft.com/en-us/library/vstudio/ms733135(v=vs.90).aspx http://msdn.microsoft.com/en-us/library/vstudio/ms733135(v=v... This should be the gold standard. In addition, it warns that even loading XML documents can be dangerous if we then load remote DTDs for validation. 5. For the old salts, remoting or RMI have similar issues - both mitigated by restricting the types that can be deserialized. http://msdn.microsoft.com/en-us/library/5dxse167(v=vs.71).aspx http://msdn.microsoft.com/en-us/library/5dxse167(v=vs.71).as... 6. Here's another vulnerability which targets serialization http://wouter.coekaerts.be/2011/spring-vulnerabilities http://wouter.coekaerts.be/2011/spring-vulnerabilities In summary, 1. all deserializers should be viewed with suspicion. 2. A deserializer which does not implement a whitelist of types that it can deserialize to is not suited for handling arbitrary data. 3. For example, it is capable to creating untainted/trusted objects in application servers, which some time later, may be used for XSS, or execution in SQL. In the Struts case, the standard Java libraries have constructors and methods that deserializing is enough to result in an arbitrary file being dropped on the remote file system.
- tptacek 14y agoVery similar vulnerabilities have definitely been discovered in other platforms. This vulnerability is most similar to the object loader vulnerabilities found in Spring a few years back. It is the kind of vulnerability that is occasionally found in Java web stacks. It is a simpler vulnerability. This is a double edged sword. On the one hand, it is easier to fix (and to be sure we've fixed) than the objectloader-type stuff. On the other hand, it's so easy to reason about and work with that the exploit is straightforward. It was very difficult to find ways to talk about the general pattern of weakness in this code without immediately disclosing the exploit. The vulnerability is similar in spirit to Python's Pickle, which is also unsafe for untrusted data. A difference between Raila and Django, though: while specific Django apps have had Pickle exposures, I'm not sure Django itself ever did. PHP has vulnerabilities that are similar in impact to this vulnerability. But there's a big difference between this flaw (and the Python issues) and PHP: PHP grappled for years and years with a publicly known bug class (remote file inclusion) that coughed up code execution. It's not impossible that more RCE flaws will be found in Rails, but it's unlikely to become a class of bug that every Rails developer will need to adopt best practices to stop. No mainstream web platform has ever survived long deployment in popular applications without some horrible finding. Nobody's hands are clean. It is very difficult to get security right in every single component that a full-featured web framework needs to offer. It only takes one mistake. You are dead right about deserializers in general.
- jasonlingx 14y agoThinking aloud, do we need some kind of auto-update feature for rails apps? This kind of exploit suddenly exposes the multitude of Rails apps out there to remote code execution. I know it wouldn't be a trivial thing to make, but we already have yum auto update for linux and auto updates for Windows, OS X etc, it should definitely be feasible. Scope could be severely limited, so for example, a monkey patch for big vulnerabilities like this, while sending a notification email to the app maker.
- charliesome 14y agoReplacing one RCE with another :)
- thewillcole 14y agoHeroku apps rely on Heroku's version of Rails gems (right?), so how does one tell if Heroku has patched these vulnerabilities yet?
- willlll 14y agoHeroku runs whatever version you say in your Gemfile. You must update your apps yourself; There is nothing Heroku can do to update your app for you.
- thewillcole 14y agoBut am I protected if I'm currently using a fixed version of Rails? (3.2.11, 3.1.10, 3.0.19, or 2.3.15)
- willlll 14y agoyes
- imforreal 14y agoSweet! I can use this to infiltrate my main competitor's site, just need to install a backdoor before he upgrades...
- chunkyslink 14y agoOk. I'm quite new to Rails. How do I apply this patch? Or am I better upgrading rails completely? How do I do this.
- elektronaut 14y agoUpdate to 3.2.11, 3.1.10, 3.0.19 or 2.3.15, and you'll be good.
- chunkyslink 14y agoAlready in my gem file ... gem 'rails', '3.2.3' I think that patch maybe? But I dont know how. Google is not helping,
- elektronaut 14y agoChange it to gem 'rails', '3.2.11' and run bundle update rails
- derwiki 14y agoI heard through the grapevine that YC affiliated companies were tipped off to this exploit/patch before it was made public (really; a YC affiliate asked me today about the vuln before it was disclosed). Could anyone comment on that?
- jgeralnik 14y agoNot necessarily anything to do with YC; the vulnerability was discovered and posted on twitter shortly after last week's vulnerability.
- tptacek 14y agoThe existence of this vulnerability (without details) was disclosed publicly last week. So far as I know, nobody was told any details about the vulnerability itself; just that a patch was coming, and it was very important to apply it.
- martinced 14y agoI'm tired of the logical fallacy that consists in always saying: "Every software suffers from security issues". It is just plain wrong to reason like this. So let me ask something to the ones using the above fallacy: are all programs (say webservers) equals in the face of security? It's an easy question right? And the answer is: "no, they're not all equal". So stop saying: "But Java had several DoS bugs affecting Tomcat in 2011 too, so we're not doing anything wrong here". And start coding (and documenting) to higher standards.
- berkes 14y agoYou make it sound as if "Every software suffers from security issues" was brought up as a reason not to put effort into security. It was not. It is very valid to reason within constraints of reality. Like knowing that a car "which will never ever have an accident. ever" is a lie. We know that driving a car brings a risk of an accident. That is realism. Some turn that reality into dangerous behaviour. Saying things like "Statistics tell me I will have an accident no matter what. So I can just as well finish this bottle of whiskey before driving at 150Km/h home". You are making it sound as if the Rails developers follow that logic. They don't. There simply is a certain realism that, no matter how much effort you put into security, there will be security issues. But nothing more. Or less.
- andrewnez 14y agoI've thrown together a little script for checking your github repos for out of date rails apps: https://gist.github.com/4492021 https://gist.github.com/4492021 Should come in handy today.
- costad 14y agoAs someone stuck maintaining an older rails app with no hope of upgrading anytime soon, any information on patching rails 2.1.0 against this vulnerability?
- wigsgiw 14y agoBest idea would be to apply the workarounds presented for Rails 2.3 in the group post: https://groups.google.com/forum/#!topic/rubyonrails-security/61bkgvnSGTQ/discussion https://groups.google.com/forum/#!topic/rubyonrails-security.... Place a couple of lines in a file in config/initializers, and you're good,.