Hacker News Board Hacker News, browsed like a classic message board
Live data from Hacker News

Multiple vulnerabilities in parameter parsing in Action Pack

groups.google.com

Post reply on HN
Print view View original

251–260 of 294 posts

Re: Multiple vulnerabilities in parameter parsing in Action Pack

#251

Post by j-kidd »

pjungwir wrote: post #57
sergiotapia wrote: post #14

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.

You are comparing library with language here. Rails is vulnerable to remote code execution. This is comparable to something like:

https://bugzilla.redhat.com/show_bug.cgi?id=854757 - CVE-2012-4406 Openstack-Swift: insecure use of python pickle()

Re: Multiple vulnerabilities in parameter parsing in Action Pack

#252

Post by Argorak »

tptacek wrote: post #154
Argorak wrote: post #60

This hits one my basic complaints about Rails: it activates too many features _by default_. Even if your app does not parse XML params, the parser is active. I know its convenient, but hey - is this worth the price of exposing _everyone_?

That's not a fair critique here. The problem isn't that Rails exposes XML by default. Everyone knew it did, and just processing XML isn't the issue. The problem is that the XML code used in the untrusted request path was also used by code that handled trusted messages elsewhere, and those trusted messages had requirements that weren't appropriate for request-path messages. Because JSON is so much more popular than XM…

Yes, it is a valid critique. You are right that just deactivating XML parsing is a reasonable workaround - and in my opinion so reasonable that it should never be activated by default in the first place.

A lot of people get bitten by a component they never consciously used and activated in the first place. While the second part is true for almost every part of a framework, the first one is problematic. ("XML? Why do I have a vulnerability through XML and YAML in a JSON-only app?")

Re: Multiple vulnerabilities in parameter parsing in Action Pack

#253

Post by jgeralnik »

derwiki wrote: post #233

I heard through the grapevine that YC affiliated companies were tipped off to this exploit/patch before it was made public (really; a YC affiliate asked me today about the vuln before it was disclosed). Could anyone comment on that?

Not necessarily anything to do with YC; the vulnerability was discovered and posted on twitter shortly after last week's vulnerability.

Re: Multiple vulnerabilities in parameter parsing in Action Pack

#254

Post by homakov »

xentronium wrote: post #124

http://www.insinuator.net/2013/01/rails-yaml/ Some explanation why YAML user input is evil. It works like this 1.9.3p327 :001 > id = YAML.load("--- !ruby/string:Arel::Nodes::SqlLiteral \"1 --\"\n") # if user input can contain arbitrary YAML "1 --" It looks like string, but it's not. 1.9.3p327 :002 > Keyword.where(:id => id).first Keyword Load (0.3ms) SELECT `keywords`.* FROM `keywords` WHERE `keywords`.`id` = 1 -- LI…

sql injection is possible, but how to work around to get remote code execution

Re: Multiple vulnerabilities in parameter parsing in Action Pack

#255

Post by batiste »

nathan_f77 wrote: post #61
sergiotapia wrote: post #14

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?

Please know that Rails is definitely very secure, and it has gone through many years of testing and review. However, no framework is immune. We should be grateful that the bug was found, patched, and notified, instead of being silently exploited by some black-hat who discovered it first. The following is speculation, but keep in mind that this bug may have been found because the Rails team has been looking for securi…

"Please know that Rails is definitely very secure"

It might be secure NOW. But restrospectively, it never was before this patch.

Re: Multiple vulnerabilities in parameter parsing in Action Pack

#256

Post by jasim »

alexanderh wrote: post #161
ghayes wrote: 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'm curious. Is there any objective data apart from your anecdotal generalizations that can justify the claims?

Most Ruby developers primarily work with Rails. I presume this is the reason you are conflating the framework with the language.

Re: Multiple vulnerabilities in parameter parsing in Action Pack

#257

Post by jasim »

alexanderh wrote: post #231
Turing_Machine wrote: post #168

Earlier quoted context omitted.

Yes, you're right. There have never been any security problems with "serious" "nonfun" languages like C, or Java, or the .NET stack. :-/ This has nothing to do with the Ruby language, by the way, any more than a hole in IIS is a problem with .NET. If you're going to talk smack, at least learn what you're talking about.

You misinterpreted my comment. I agree, the language is largely inconsequential. Its the culture around the language that is the problem. Ruby's is particularly bad. All I'm saying is the "1000 ways todo the same thing" nature of Ruby, has the unfortunate consequence of attracting newbs, and making 'best practices' hard to nail down. Other languages tend to have more support in corporate/educational areas, tend to ha…

I haven't seen many seasoned developers claiming PHP is a 'fun' language to program in. It was my first web development language and it was fun back then. But the honeymoon period gets over quickly once you realize the limitations of the language and see what other languages like Ruby has to offer.

Re: Multiple vulnerabilities in parameter parsing in Action Pack

#258

Post by subsystem »

steveklabnik wrote: post #181
subsystem wrote: post #170

Earlier quoted context omitted.

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.

There are specific things that could be said about the bug in question, like not being secure by default, but this doesn't fix the underlying problem. The development team should recognize that security is an important part of the project and act accordingly.

Re: Multiple vulnerabilities in parameter parsing in Action Pack

#259

Post by berkes »

martinced wrote: post #238

I'm tired of the logical fallacy that consists in always saying: "Every software suffers from security issues" . It is just plain wrong to reason like this. So let me ask something to the ones using the above fallacy: are all programs (say webservers) equals in the face of security? It's an easy question right? And the answer is: "no, they're not all equal". So stop saying: "But Java had several DoS bugs affecting To…

You make it sound as if "Every software suffers from security issues" was brought up as a reason not to put effort into security. It was not.

It is very valid to reason within constraints of reality. Like knowing that a car "which will never ever have an accident. ever" is a lie. We know that driving a car brings a risk of an accident. That is realism. Some turn that reality into dangerous behaviour. Saying things like "Statistics tell me I will have an accident no matter what. So I can just as well finish this bottle of whiskey before driving at 150Km/h home". You are making it sound as if the Rails developers follow that logic.

They don't. There simply is a certain realism that, no matter how much effort you put into security, there will be security issues. But nothing more. Or less.

Post reply on HN