What The Rails Security Issue Means For Your Startup • Hacker News Board

Re: What The Rails Security Issue Means For Your Startup

#61

Post by Spakman » Thu, Jan 31, 2013, 6:19 PM UTC

NelsonMinar wrote: post #27

pifflesnort wrote: post #3

The "everybody has bugs" response is intellectually dishonest. Yes, everybody has bugs, but most people's bugs aren't an intentional feature that a trained monkey ought to have known was a bad idea. - Someone implemented a YAML parser that executed code. This should have been obviously wrong to them, but it wasn't. - Thousands of ostensible developers used this parser, saw the fact that it could deserialize more than…

What is crazy to me is everyone has had this bug, and learned from it, and fixed it. Why has it taken so long for Rails? Java has this bug; you can't deserialize untrusted input without a lot of work. Python has this bug; you can't unpickle untrusted input. Bad Javascript JSON parsers that just call eval() have this bug. It's not a complicated concept; you can't treat untrusted user input as code to execute. How'd th…

Presumably they missed it the same way the developers of those other things you listed did. I can only assume they didn't know about these other problems when developing their YAML parsers.

Of course, you could argue that developers should always be thinking about and searching for security related issues in whatever field they're working in, but that doesn't appear to be the norm at the moment.

Re: What The Rails Security Issue Means For Your Startup

#62

Post by purephase » Thu, Jan 31, 2013, 6:20 PM UTC

boonedocks wrote: post #39

purephase wrote: post #10

Earlier quoted context omitted.

Probably not safe enough as most of them probably list external dependencies that will fall back to rubygems.

I'm not sure of the best way to go about it, but if all the dependency gems are also on Github, a script might be able to pull the SHAs from the right version of each dependency and return the proper entries for a Gemfile.

gemspecs/Gemfiles rarely list the gh repo, so you'll likely have to get it from a source which is probably rubygems. If it's compromised, they could update the gh repo location as well.

Re: What The Rails Security Issue Means For Your Startup

#63

Post by jcampbell1 » Thu, Jan 31, 2013, 6:21 PM UTC

It would be interesting if someone wrote a worm that just took all the vulnerable rails apps offline. That way we would have less worry about a million compromised databases. It could be launched from a bookmarklet run from tor browser, and would probably exhaust every ip address in a few days. It would also land whoever did it in jail for a really long time.

Re: What The Rails Security Issue Means For Your Startup

#64

Post by pifflesnort » Thu, Jan 31, 2013, 6:24 PM UTC

netshade wrote: post #49

pifflesnort wrote: post #43

Earlier quoted context omitted.

> It may not be as cathartic for you, but I'd suggest toning it down to "reasonable human being" level in the future. The Rails community has exhibited such self-assured, self-promotional exuberance for so long (and continues to do so here), it feels necessary to rely on equivalently forceful and bellicose language to have a hope of countering the spin and marketing messaging. Case in point, the article seriously say…

I can understand your frustration with the community. I share this frustration at many times, because I feel that Rails / Ruby tends to value style over substance. I'll also raise an eyebrow at that particular sentence, though without spending much time looking into what's backing it I can only add that I too find that slightly incredulous. I definitely question your stated intent. Were you to "counter the spin and m…

> Overall, reduce the number of people that use Ruby/Rails, if that is your intent? Given the number of comments you've made to that effect versus the number of folks using Ruby/Rails, I'd suggest you have a very long battle in front of you.

I'd like it to be 'cool' in the Ruby community to apply serious care towards security, API stability, code maintainability, and all the other things that aren't necessarily fun, but are very much necessary to avoid both huge aggregate overhead over time, and huge expensive failures like this one.

I'd like to see a shift towards an engineering culture where taking the time to consider things seriously is considered 'cooler' than spinning funny project names, promoting swearing in presentations, and posting ironic videos.

It seems increasingly obvious to me that for this to occur, one can succeed in pushing back against emotive marketing with a similar approach, and thus shift the conversation.

Re: What The Rails Security Issue Means For Your Startup

#65

Post by thibaut_barrere » Thu, Jan 31, 2013, 6:25 PM UTC

newman314 wrote: post #51

jroes wrote: post #31

Earlier quoted context omitted.

I'm willing to bet if you put someone like benmmurphy, ptacek, or homakov in your codebase he'll have you begging for a web framework in hours.

I wonder if various companies pooled money for a comprehensive audit of rails by ptacek etc., one would think that's a win-win for all.

I wondered exactly the same thing, a security-chase kickstarter or similar.

Re: What The Rails Security Issue Means For Your Startup

#66

Post by lucian1900 » Thu, Jan 31, 2013, 6:27 PM UTC

patio11 wrote: post #34

ontoillogical wrote: post #28

Earlier quoted context omitted.

I'm not sure I get what you're the analogy to. When I first read your blog post I got the impression that you were saying that the YAML vulnerability were found with some new code scanning technology that lets us find bugs in Rails faster. Or are you just saying discovering the existence of the YAML.load() class of vulnerability is "new security technology?" Or are you talking about the ronin support module people ar…

So if I had told you at Christmas three salient facts: + Some objects are unsafe to instantiate if you don't pick all values you initialize them with very carefully. + YAML can instantiate objects from any class. + Rails uses YAML, in a lot of ways. You might have said "Yes, I am aware of all these three things. Do you have anything important to tell me?" Now, if I demonstrate to you working PoC code which combines t…

Anyone competent would, when knowing those three things, immediately think of the possible exploits.

Re: What The Rails Security Issue Means For Your Startup

#67

Post by jaequery » Thu, Jan 31, 2013, 6:27 PM UTC

tomjen3 wrote: post #22

purephase wrote: post #11

Earlier quoted context omitted.

As a temporary workaround until Psych is updated. At least that's how I read it. We can either sit around throwing stones at them or pull up our sleeves and help. I'm not sure what there is to gain with the former.

Rails needs to die. It is super nice to code in (for a certain class of problems, ie. CRUD apps) and the language is awesome but it is too big and insecure to use.

rails don't need to die, but seeing how ruby devs like bashing other languages, this event seems to me like karma.

Re: What The Rails Security Issue Means For Your Startup

#68

Post by lucian1900 » Thu, Jan 31, 2013, 6:33 PM UTC

To me it seems that all of this is due to the obsession with implicit behaviour in Rails, and to some extent Ruby.

I hope they learn from this and stop chanting "convention over configuration" when told that explicit is better than implicit.

Re: What The Rails Security Issue Means For Your Startup

#69

Post by alexch » Thu, Jan 31, 2013, 6:35 PM UTC

NelsonMinar wrote: post #27

pifflesnort wrote: post #3

The "everybody has bugs" response is intellectually dishonest. Yes, everybody has bugs, but most people's bugs aren't an intentional feature that a trained monkey ought to have known was a bad idea. - Someone implemented a YAML parser that executed code. This should have been obviously wrong to them, but it wasn't. - Thousands of ostensible developers used this parser, saw the fact that it could deserialize more than…

What is crazy to me is everyone has had this bug, and learned from it, and fixed it. Why has it taken so long for Rails? Java has this bug; you can't deserialize untrusted input without a lot of work. Python has this bug; you can't unpickle untrusted input. Bad Javascript JSON parsers that just call eval() have this bug. It's not a complicated concept; you can't treat untrusted user input as code to execute. How'd th…

My analysis: layering. YAML doesn't in itself execute untrusted code, but it has a bunch of semi-experimental features most people don't know about or use, and one of those features (deserializing arbitrary classes) has a side effect that sets values on certain other classes -- not written by the people who wrote the YAML parser -- that then, often later on in their lifecycle, execute this untrusted code. I'm not saying this as an excuse -- I have long mistrusted YAML's blasé complexity, not to mention Rails' anarchic pass-HTTP-params-directly-into-the-DB pattern -- but as an explanation of how they missed it.

Also, more than other communities, Ruby has a cultural gap between the people developing the language and core libraries and the people using it to write web apps and frameworks.

Here's two good technical writeups of the exploit as it applies to Rails apps: http://blog.codeclimate.com/blog/2013/01/10/rails-remote-cod... http://ronin-ruby.github.com/blog/2013/01/09/rails-pocs.html

Re: What The Rails Security Issue Means For Your Startup

#70

Post by hawleyal » Thu, Jan 31, 2013, 6:42 PM UTC

FUD much