20 ms·
Vulnerability in JSON Parser in Ruby on Rails 3.0 and 2.3
- instakill 14y agoHooray for 3.1 and 3.2 apps.
- cschneid 14y agoDamnit, I'm busy fixing the devise issue!
- benatkin 14y agoI missed that. Here's a link in case anyone else missed it: https://groups.google.com/forum/?fromgroups=#!topic/plataformatec-devise/hj6i26Dvshw https://groups.google.com/forum/?fromgroups=#!topic/platafor...
- ecoffey 14y agoWell at least you're in "pushing fixes to prod" mode :-D
- mars 14y agoHang in there. New work will arrive soon :)
- matthuggins 14y agoCan someone explain the security issue in more detail? Is it that I can supply Symbols (and other Ruby objects) in my YAML, which normally can't be included in JSON? That seems to be the basis of it, but I'm looking for more info if available.
- jmillikin 14y agoThe Rails YAML parser allows execution of arbitrary Ruby code, by design. If an attacker can figure out how to get input into the YAML parser, they win.
- tveita 14y agoThat's awful. This seems to be something of a theme with RoR. XML parsers that parse YAML, JSON parsers that parse YAML, YAML parsers that parse Ruby... Why would they let that mess near user input? I thought Ruby included a proper JSON parser now.
- knowtheory 14y agoIt does now. But it didn't in versions <3.1.
- postmodern_mod3 14y agoYAML does not allow execution of arbitrary Ruby code. Some YAML types allow specifying a custom class, which the Psych YAML parser (default in Ruby 1.9) will call the initialize or []= methods. If you can find a class that eventually evals() input passed to initialize or []=, then you win. http://ronin-ruby.github.com/blog/2013/01/09/rails-pocs.html http://ronin-ruby.github.com/blog/2013/01/09/rails-pocs.html
- postmodern_mod3 14y agoCheckout the lengthy write-up for the original vulnerability. http://ronin-ruby.github.com/blog/2013/01/09/rails-pocs.html http://ronin-ruby.github.com/blog/2013/01/09/rails-pocs.html
- matthuggins 14y agoThanks for the link, but it looks like that's for CVE-2013-0156 and CVE-2013-0155. This HN post is about CVE-2013-0333. It does look like there's a newer blog post about this issue though: http://ronin-ruby.github.com/blog/2013/01/28/new-rails-poc.html http://ronin-ruby.github.com/blog/2013/01/28/new-rails-poc.h...
- postmodern_mod3 14y agoTook a while to write a new blog post. Still, CVE-2013-0333 relies on the same YAML deserialization technique as CVE-2013-0156, so all the previous information is still relevant.
- benmmurphy 14y agoit appears that some versions of rails parsed JSON by first converting it to YAML then performing YAML.load I think they wanted a json parser but they didn't want to write one. So they basically just wrote: YAML.load(json.gsub(/awesomeregex/, "awesomereplace"))
- molf 14y agoYAML is a superset of JSON. So this works just fine to parse JSON (with the caveat it parses any YAML and is therefore not secure): YAML.load(json)
- benmmurphy 14y agoah. i wonder if there isn't any json stuff that yaml doesn't support because the convert_json_to_yaml method does a bit of munging. if you take a previous PoC and feed it raw without any modification it corrupts it and makes it invalid yaml. for example convert_json_to_yaml will put spaces around the ':' character.
- molf 14y agoI think that kind of processing is just to work around bugs in the old YAML parser (syck). See this post for example: http://project.ioni.st/post/1067 http://project.ioni.st/post/1067
- eric970 14y agoGreat news. It's good that all of these bugs have been surfacing lately.
- instakill 14y agoI don't know why this is being downvoted - I don't think this comment is sardonic. It IS good that they're surfacing because that means we can patch them. Better visible than invisible.
- sandofsky 14y agoIt isn't good. Similar projects with a similar user base, like Django, don't have vulnerabilities of this severity with this frequency. This points to a seriously broken process.
- PetrolMan 14y agoIt isn't a bad thing necessarily. Just because the vulnerabilities haven't popped up in other frameworks doesn't mean they aren't there.
- sandofsky 14y agoThat's creationist logic.
- navyrain 14y agoHardly the same. Lets not kid ourselves into thinking any of the popular software we use is bug-free, which is nigh impossible feat for any large codebase. If this rails bug had not been discovered, it would still be there.
- sandofsky 14y agoWho said software is bug free? The issue is that similar projects, with similar success, with a similar number of developers looking at them, have fewer severe vulnerabilities. The simplest explanation is that one project has more vulnerabilities lying dormant.
- eggbrain 14y agoWould it ever be possible to have a self-updating framework? As in, I use Rails to develop web applications. In the past months, I've had to painstakingly go back to every single app I've ever worked on, and manually update it in whatever minor way it needed updating. Now, I'm going to do that again. If you consider that I'm going to continue to build Rails applications, the number of apps I will have to update every time a security vulnerability comes out will be larger and larger. For a framework that prides itself on sane defaults, it doesn't seem quite sane to have to worry about taking down, updating, and then relaunching every app you ever had when one of these vulnerabilities come out. I don't mean updating a Rails 2.3 app to 3.2 automatically, just applying these security patches automatically, or prompting the user to do so. Our operating systems do it, our IDEs do it, our programs do it, why can't a framework? I'm not saying it would be easy, but I'm sick of having to be subscribed to these email groups just to start the manual process of fixing everything.
- kmfrk 14y agoI think it would have to be handled by the platform provider. Someone like Heroku could make it happen. Or you could set up a cron-like worker to perform a pip-review (https://github.com/nvie/pip-tools https://github.com/nvie/pip-tools) of sorts. I don't know if I like the idea of a single point of failure; whatever service pushes the update would have a big, fat Wile E. Coyote target on its back. I am currently trying to figure out something similar for a Django-based app at the moment. I include a version in the settings file that I plan on comparing against some sort of version array on a central website. If a new security update is available, a conditional notification will show up for admins, but they will still have to update somewhat manually - I can't set up a cron job to trigger the whole procedure, especially because it might wreck their service, depending on how it works.
- eggbrain 14y ago'I don't know if I like the idea of a single point of failure; whatever service pushes the update would have a big, fat Wile E. Coyote target on its back.' This is a solved problem though, right? Antivirus companies deal with this when they push out definition updates that render backdoors ineffective, and yet while they probably are targeted by the virus makers, they have been quite resilient.
- ollysb 14y agoThere's been a lot of rails bugs coming up lately, why are so many being found at this particular point in time? Who's finding them and what's spurred their interest?
- swang 14y agoThis is related to YAML loading (I believe) so it is somewhat related to the major bug from a couple of weeks ago. My guess is someone went through the Rails code combing for any interaction with YAML that wasn't caught last time.
- benmmurphy 14y agoI have remote code execution working when YAML syck parser is being used. I've also got RCE working when psych is used (default in 1.9.x) using a similar trick to syck.
- vinhboy 14y agoI know you're not supposed to share these things, but I found it really useful how last time there were public PoC we could use to test our patches. Any such thing this time around?
- benmmurphy 14y agopostmodern just posted he found it on twitter. so i would expect public PoCs/metasploit code to be released soon.
- postmodern_mod3 14y agoHere you go: https://gist.github.com/4660248 https://gist.github.com/4660248
- vinhboy 14y agothanks
- deleted 14y ago[deleted]
- deleted 14y ago[deleted]
- static_typed 14y agoThe smell of late night coffee, having to update Ruby on Fails yet again, or better, the colder more bitter coffee in the morning, when having to offline and rebuild a compromised server due to this framework. It started with such promise, and now, we are looking to migrate all Rails apps off to alternative frameworks at the first opportunity. It really is a shame.
- M4N14C 14y agoSomething had a problem! Better rewrite everything. All software has bugs, the pain involved in updating a gem and running test tests is very low. Instead of complaining, update your gems. I'm sure that there would be no security holes if you wrote everything from scratch.
- wasd 14y agoOut of curiosity, which frameworks are you moving to?
- mylittlepony 14y agoIf you don't mind using php, Symfony2 seems to be as professional as you can get. I moved from Rails to Symfony2 and never looked back.
- koide 14y agohttp://symfony.com/blog/security-release-symfony-2-0-22-and-2-1-7-released http://symfony.com/blog/security-release-symfony-2-0-22-and-... As above, so below. This is not to diss Symfony, on the contrary, I believe having vulnerabilities detected does not mean the framework is insecure or not to be trusted. What's not very logical is changing frameworks to another with a similar track record on the security camp due to some vulnerabilities found.
- mylittlepony 14y agoHave you even read that? > Symfony applications are not vulnerable to this attack And it definitely has not the same track record. For example, it has been audited by a security company in one of the first versions. So far I have only seen minor security vulnerabilities, nothing like what Rails brings every week. Anyway, that's not why I changed. I found it to be much better architected, 100% decoupled (as opposed to monolithic). You can change anything you want if you have to, or if you find better vendors and want to try them. It has actually been designed from day 1, and not by someone who has read about design patterns little time before creating the framework, and calls himself 'the master chef'. Having an OOP background, I thought (I don't remember why) Ruby/RoR community was some sort of elite, and everyone had a much higher minimum level (as opposed to php, where most people are noobs). I was disappointed, most of them didn't even understand what interfaces were for (no wonder ruby hasn't added them yet), let alone knowing the most basic design patterns. They also seem to enjoy laughing at developers from other languages. All this was a pain to watch, but I didn't care as long as Rails was perfect, and that's how I felt about it at first. But it wasn't, so I moved to Symfony2, and found out not only the framework was superior, but also the community was awesome.
- veloper 14y agoIf everyone is really going to take the route of "My X Framework is fine b/c nothing's been reported" then I'd like to contribute these links showing vulnerability break downs... * Rails: http://www.cvedetails.com/product/22568/Rubyonrails-Ruby-On-Rails.html?vendor_id=12043 http://www.cvedetails.com/product/22568/Rubyonrails-Ruby-On-... * Django: http://www.cvedetails.com/product/18211/Djangoproject-Django.html?vendor_id=10199 http://www.cvedetails.com/product/18211/Djangoproject-Django... * CodeIgniter: http://www.cvedetails.com/product/11625/Codeigniter-Codeigniter.html?vendor_id=6918 http://www.cvedetails.com/product/11625/Codeigniter-Codeigni... * Top 50 Products (Better stop using these too! /s): http://www.cvedetails.com/top-50-products.php http://www.cvedetails.com/top-50-products.php
- justsee 14y agoInteresting. Rails: numerous code execution and SQL injection vulnerabilities reported over the years. Django: no code execution or SQL injection vulnerabilities reported.
- sil3ntmac 14y ago(yet).
- tedunangst 14y agoTo be honest, rails does seem to be going out of its way to increase its attack surface.
- eric970 14y agoThank you.
- glfomfn 14y agoYou are shooting your own feet with these links you know. According to your data Django had -ZERO- sql injections & code execution repots, now compare that to RoR which had 6 sql injections & 3 code execution reports since 2009. Even if you went by just the numbers RoR had way more vulnerabilities, now if you also take in consideration the kind of vulnerabilities i can tell you i feel way safer on django than RoR. How many times did you have to stay up late at night to patch your framework ?
- hayksaakian 14y agoThis doesn't actually affect rails 3.1+ Awesome.
- mjhoy 14y agoQuick & dirty find (for Rails apps 3.0.x) find ~/rails -name 'Gemfile' -exec grep -E "rails', '3.0" {} \; -print
- hemancuso 14y agoThe only meaningful take-away from these continued security vulnerabilities is you shouldn't ever let a rails project you maintain ossify to the extent that you can't easily/safely run "bundle update", commit, and deploy. (Didn't expect to post this comment twice today, JFC)
- PommeDeTerre 14y agoWell, there's also an issue of trust that I think is being overlooked. We now need to ask ourselves, "Can we trust the Ruby community, and can we trust software written in Ruby?" Before these recent exploits, there were a lot of us who would have already answered "no" to both parts of that question. Now there may be many more people who answer them the same way. The warning signs have been there for a long time. The general attitude of the Ruby community is one of these warning signs. The smugness, the emphasis on "best practices" (which usually aren't very good, in reality) and the drama and semi-religious worship surrounding certain members of the community (DHH, Zed, and _why) are what I'm talking about. This kind of attitude promotes an environment where bugs can happen in the first place, then go undetected, and in many cases also go unpatched once discovered. At this point, I think it's necessary to scrutinize the Ruby community and their software much more closely than has been done in the past. The complacency of the past is not acceptable any longer, given what has happened recently.
- sil3ntmac 14y agoHere's the fix: https://github.com/rails/rails/pull/8853/files#L1L35 https://github.com/rails/rails/pull/8853/files#L1L35 Happy hacking!
- jrochkind1 14y agoHmm, I'm curious of the story behind this vulnerabilty NOT existing in 3.1 and 3.2. How the heck did it get fixed in 3.1 and 3.2, but still exist in 3.0 and 2.3? It was accidentally fixed in 3.1? It was on purpose fixed in 3.1, but it didn't occur to the fixer to backport to 3.0 and 2.3? Eh?
- postmodern_mod3 14y agoProof-of-Concept exploit: https://gist.github.com/4660248 https://gist.github.com/4660248
- patio11 14y agoThis simple command line tool to execute arbitrary code on your server works, kids. I'm also north of 90% probable that I could weaponize it to turn any image tag on the Internet into "roots your local machine", and 100% certain I could do so for any page I could coerce to execute JavaScript. You need to patch. Now.
- postmodern_mod3 14y agoBonus points if you exfiltrate config/initializers/secret_token.rb.
- spohlenz 14y ago> I'm also north of 90% probable that I could weaponize it to turn any image tag on the Internet into "roots your local machine" Definitely not saying you're wrong, but I'm not convinced this is doable. Every exploit I've seen requires a request body -- how would you do that with an IMG tag?
- patio11 14y agoGo on a Rails security safari, armed with the knowledge that any YAML parsing is victory, and pay very careful attention to code paths involving Rails/Rack route/parameter processing, especially anything which smells of magic. To clarify: I haven't actually done the work yet. I'm actually going on a Rails security safari later, though not particularly looking to widen this/these vulnerabilities. I figure I've gotten enough out of the community over the years to contribute part of a workweek and get one more hole plugged.
- postmodern_mod3 14y agoNot unless nginx/apache routes the request directly to public/. There will definitely be more code-paths to YAML.load, but so far ActionDispatch::Http::Parameters has been the entry point.
- jacobn 14y agoIf I've disabled the JSON MIME type as input, a la the workaround to the XML issue a couple of weeks ago, am I safe against this vulnerability?
- jballanc 14y agoNull terminated strings are simple to understand and convenient to work with...until they can be exploited. Non-bounds-checked arrays are fast and convenient to work with...until they can be exploited. Database queries using interpolated strings are flexible and convenient to work with...until they can be exploited. Serialization formats that can encode arbitrary objects are useful and convenient to work with...until they can be exploited. ...and the collective wisdom of the programming world continues its relentless, gradual, monotonic increase.
- rurounijones 14y agoWhy is it only Rails issues seem to be so popular on HN? Is it the lovers wanting to spread the word for their rails colleagues using it. Or is it the haters enjoying the schadenfreude. No other framework seems to get as much publicity on HN whenever something goes wrong.
- jtchang 14y agoSo who is hosting the rails security update party this time? Is there some magic command I am missing to update all rails projects I've ever worked on automatically? "gem super-update-everything"
- jiggy2011 14y agoI wonder if it's worth someone putting together a kickstarter so that all of these rails dependant startups can crowd finance hiring some penetration test firms to do a thorough audit of the entire rails codebase?