Hacker News Reader

Comment by chimeracoder | Hacker News Reader

> The bug in the YAML parser was reported and the author of the YAML library genuinely couldn't figure out why this mattered or how it could be bad.

Is that seriously what happened? It sounds oddly similar to the Rails issue from about a year ago (the one in which the reporter was able to commit to master on Github), even though I believe that was a separate set of developers altogether.

If so, then that might suggest a larger community/cultural issue, which makes me wonder what other exploits exist but haven't been reported (publicly) yet...

View on HN

> Is that seriously what happened?

Surprisingly, yes: https://github.com/tenderlove/psych/issues/119

And the RubyGems folks are trying to handle this with whitelisting specific classes that the YAML parsing will still be allowed to instantiate:

https://github.com/rubygems/rubygems.org/pull/516/files

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.

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.

Anything you implement to replace the functionality missed by not using Rails will be, statistically, just as insecure. Arguably, even more-so because you will no doubt lack the peer review a large project like Rails benefits from.

Unless you implement it in a fundamentally simpler way.

I don't think so. Rails has to cover all cases, you just have to code the few cases that you actually use.

And even if you get it wrong, you get it wrong in a different way. That might mean that you are technically more at risk, but so long as the attack is focused on getting as many targets as possible, rather than you explicitly, then that is arguably a great strategy: the cost of adapting an already existing attack to target a novel target is going to be astronomically high, versus using an already existing vulnability. If you are refining neuclear material for Iran, you are going to need all the protection you can get; if you are just another start-up you just need not to be vulneable to the latest drive-by exploit.

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

Some ruby devs do, yes. Sadly, this feudalistic approach is prevalent in our industry which hurts all of us. It is probably the reason we have to keep re-learning the same concepts over-and-over again.

There is no karma here, there is just a race to the bottom for all of us. I thought the point of OS was for us all to group together and find and address these issues?

You know, kumbaya and all that...

Can we please try to avoid making generalisations like this? Yes, the ruby community has some very vocal contributors with very questionable social skills. Please don't assume that all ruby developers are egotistical hipster hackers. The creator or Ruby, Matsumoto Yukihiro is one of the most softly spoken and humble individuals I have encountered in technology. We can all learn by his example.

I agree with the sentiment to help and not just throw stones, but I think all the outrage and whatnot is very useful: it makes this kind of stuff less likely to happen.

Different issue altogether. It was mass-assignment wherein the default Rails config did not have the whitelist enabled by default. The howto is here:

http://homakov.blogspot.ca/2012/03/how-to.html

I know it was a different vulnerability - I was asking more whether the same developer(s) was/were responsible, since this seems to be a comment pattern that I'm hearing with regards to the initial response to the vulnerabilities.

Actually it is the same issue as basically all other security issues in web programming (attack on crypto aside):

Failure to blacklist non-conforming input.

Really, it is that simple and that complicated.

Wouldn't whitelisting conforming input be a better approach? I realize it may be more difficult, but wouldn't that be more secure?

Edit: I'm genuinely interested - I always try and whitelist things when I'm building software. Although I have next to no background when it comes to security in particular.

Whitelisting is what Rails did to get around the mass assignment issue. It was solved for awhile, it just was not the default configuration setting.

Whitelisting is what the rubygems folks are doing to work around this problem until a better implementation is put in-place in the YAML parser.

Generally, it is a better solution but it is more difficult and can break a lot of dependencies if not implemented correctly.

Stupid me. I meant to write whitelisting.

Yes, you are absolutely right.

> It sounds oddly similar to the Rails issue from about a year ago (the one in which the reporter was able to commit to master on Github)

Hey, yes, yaml bug is _very_ similar. Whitelist is better than no list at all

Reply on news.ycombinator.com