Live data from Hacker News

Multiple vulnerabilities in parameter parsing in Action Pack

groups.google.com

51–60 of 294 posts

Re: Multiple vulnerabilities in parameter parsing in Action Pack

#51

As 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?

I'm in a similar boat. I've just began with Rails in the last six months, and I've really been enjoying it. These vulnerabilities are unnerving but I am comforted by the visibility of the announcements. The community seems to get the message out very quickly when an exploit is found/patched. My entire Twitter feed is filled with Rails developers telling others to upgrade immediately, and HN has multiple new posts about it.

Re: Multiple vulnerabilities in parameter parsing in Action Pack

#52
post #44

As 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?

Who'd have thought it? Hugely dynamic language turns out to be difficult to audit or analyse for security issues. It was never about Java(C, C++) vs. Ruby despite what fanboys on either side made out. It was about conservative vs. devil-may-care. All that "convenience" and "it's so clean" came at the price of a whole load of code executed behind the scenes. You didn't write it, and the Gods of TDD preached that you d…

This is a straw man.

These kinds of issues are open to all software.

I'm happy you work in the kind of place that audits all of its software, though. I'm sure you've all read through all of Hibernate, Spring and not to mention all the .NET framework code.

Re: Multiple vulnerabilities in parameter parsing in Action Pack

#53
post #46

I 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.

The 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.

Makes perfect sense. Thanks for pointing this out.

Re: Multiple vulnerabilities in parameter parsing in Action Pack

#54

For 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/

I don't think this is very responsible of you. You should post this, but you should really wait a week or so.

Re: Multiple vulnerabilities in parameter parsing in Action Pack

#55

I 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.

I'd guess multiple people working together, or multiple people who got hit by someone exploiting it in the wild.

No, it was discovered by multiple teams independently, and not from exploitation in the wild.

Re: Multiple vulnerabilities in parameter parsing in Action Pack

#56
post #22
post #15

Earlier quoted context omitted.

I 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?)

I think it's better to not discuss this openly for a few days. The exploit isn't obviously (as you've noticed) so hopefully users will be able to upgrade before the script kiddies discovers this.

In the meantime, can you confirm that the disabling of XML and YAML inputs fully mitigates the RCE as well as the SQLi?

Re: Multiple vulnerabilities in parameter parsing in Action Pack

#57

As 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?

If you read the insinuator.net article posted elsewhere on this thread, you'll see that Java (Struts), PHP, and Python have all had their own remote-code-execution vulnerabilities over the years.

Re: Multiple vulnerabilities in parameter parsing in Action Pack

#58
post #22

Earlier quoted context omitted.

I think it's better to not discuss this openly for a few days. The exploit isn't obviously (as you've noticed) so hopefully users will be able to upgrade before the script kiddies discovers this.

In the meantime, can you confirm that the disabling of XML and YAML inputs fully mitigates the RCE as well as the SQLi?

Yes.

Re: Multiple vulnerabilities in parameter parsing in Action Pack

#59

I 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.

You 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.
Post reply on HN