Live data from Hacker News

Multiple vulnerabilities in parameter parsing in Action Pack

groups.google.com

181–190 of 294 posts

Re: Multiple vulnerabilities in parameter parsing in Action Pack

#181

Earlier quoted context omitted.

> why isn't there more of a focus on security here? More compared to what, exactly? This vulnerability was responded to pretty damn quickly after it was reported, given that almost nobody is even paid to work on Rails. If you saw Aaron tweeting about "working over the weekend" a few days ago, well, now you know. That said, you mention attr_accessible in your post: that's gone as of the next release of Rails. Basicall…

I really hope this isn't the sentiment of the RoR community. There has to be a place for critique when it's warranted. At this scale it's not a joke any more, you ask for what you need and otherwise you do less.

I specifically asked them to elaborate on what could be made better.

Re: Multiple vulnerabilities in parameter parsing in Action Pack

#182

Earlier quoted context omitted.

> why isn't there more of a focus on security here? More compared to what, exactly? This vulnerability was responded to pretty damn quickly after it was reported, given that almost nobody is even paid to work on Rails. If you saw Aaron tweeting about "working over the weekend" a few days ago, well, now you know. That said, you mention attr_accessible in your post: that's gone as of the next release of Rails. Basicall…

Nothing gives me confidence in a platform like "almost nobody is even paid to work on Rails."

I'm sure some Core developers would love your sponsorship to give even more time to devote to Rails development.

Even without the money, this issue was dealt with swiftly. See the comments below about 'the Rails security team is the best vendor I've worked with.'

Re: Multiple vulnerabilities in parameter parsing in Action Pack

#183
post #40

Earlier quoted context omitted.

As there have been many exploits / issues recently realized in parameters parsing, why isn't there more of a focus on security here? Specifically, this is where users/hackers can put ANY DARN THING THEY WANT and your server has to deal with it. As a simple solution, one could pass a signed auth-hash of the fields generated by form_for, and the server could re-hash the fields submitted to ensure the form data you aske…

>why isn't there more of a focus on security here? Because this is ruby we're talking about. A "Fun" language that has 100000 ways todo the same thing, so newbs find it fun and easy. You can almost guess how the language works and almost always be right. Thats cool, great for learning, makes you feel like a superstar when you're just getting started with programming... but its really not such a good thing when it com…

I guess you could consider this the "non-programmer opinion". Otherwise known as bullshit.

Re: Multiple vulnerabilities in parameter parsing in Action Pack

#184

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

Good thing you don't have a tin foil hat, because you are way too stupid to own one responsibly.

Re: Multiple vulnerabilities in parameter parsing in Action Pack

#185
post #180

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

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

Re: Multiple vulnerabilities in parameter parsing in Action Pack

#187
post #162
post #110

Earlier quoted context omitted.

Yes, 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.

Just 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! :)

Well, 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.

Re: Multiple vulnerabilities in parameter parsing in Action Pack

#188
Thinking 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.

Re: Multiple vulnerabilities in parameter parsing in Action Pack

#189

Earlier quoted context omitted.

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

But it was not knowledge to the general public until today. That's what matters. Those people have POCs, but they're not spreading them.

One 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

Re: Multiple vulnerabilities in parameter parsing in Action Pack

#190
post #162
post #110

Earlier quoted context omitted.

Yes, 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.

Just 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! :)

That's the reason I do not publish a full list of Rails driven sites I have in my database at http://isItRails.com/
Post reply on HN