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.
Multiple vulnerabilities in parameter parsing in Action Pack
181–190 of 294 posts
Re: Multiple vulnerabilities in parameter parsing in Action Pack
#182Earlier 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."
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
#183Earlier 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…
Re: Multiple vulnerabilities in parameter parsing in Action Pack
#184Github.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.
Re: Multiple vulnerabilities in parameter parsing in Action Pack
#185I 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…
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
#186Github.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.
Re: Multiple vulnerabilities in parameter parsing in Action Pack
#187Earlier 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! :)
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
#188Re: Multiple vulnerabilities in parameter parsing in Action Pack
#189Earlier 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.
I think you underestimate your adversary. https://twitter.com/mikko/status/288766998228393984
Re: Multiple vulnerabilities in parameter parsing in Action Pack
#190Earlier 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! :)