Multiple vulnerabilities in parameter parsing in Action Pack • Hacker News Board

Re: Multiple vulnerabilities in parameter parsing in Action Pack

#231

Post by alexanderh » Wed, Jan 09, 2013, 4:46 AM UTC

Turing_Machine wrote: post #168

alexanderh wrote: post #161

Earlier quoted context omitted.

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

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 have more money backing them, tend to have more 'best practices', tend to have more rigorous testing and review. Ruby is the hipster hacker's language.... and the quality of code shows this. (in the core of the language, and by the individuals who use it)

Other languages absolutely have these problems too, but it has been my experience that Ruby is particularly bad. You are welcome to disagree with that part.

But IMO it makes sense. The quick and dirty 'million ways todo the same thing' nature of Ruby breads this kind of culture. I certainly didnt mean to single out interpreted languages tho, or imply other languages dont have security problems, or unique issues with their cultures.

PHP is probably about just as bad. I'd put Ruby and PHP high up on the 'fun to program in' list, and low on the 'secure, quality languages' list.

Re: Multiple vulnerabilities in parameter parsing in Action Pack

#232

Post by bascule » Wed, Jan 09, 2013, 4:48 AM UTC

ghayes wrote: post #40

tenderlove wrote: post #16

I'm just commenting here so that people can have a central thread for love / hatred. ;-) But seriously. This is extremely critical, please upgrade!

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…

That's an interesting suggestion but it has nothing to do with the problem at hand.

The problem here was a feature somewhat haphazardly added to Rails for ActiveResource was turned on-by-default and enabled features that should only be active for interactions with trusted clients (i.e. authenticated services running in your own infrastructure)

Your suggestion is not without merit, but this is a case of having to learn to walk before you learn to run. There are clearly much more egregious parameter parsing vulnerabilities which need to be solved before the things you're describing would ever make it into rails-core.

Re: Multiple vulnerabilities in parameter parsing in Action Pack

#233

Post by derwiki » Wed, Jan 09, 2013, 4:52 AM UTC

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?

Re: Multiple vulnerabilities in parameter parsing in Action Pack

#234

Post by charliesome » Wed, Jan 09, 2013, 4:52 AM UTC

jasonlingx wrote: post #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 vul…

Replacing one RCE with another :)

Re: Multiple vulnerabilities in parameter parsing in Action Pack

#235

Post by marshray » Wed, Jan 09, 2013, 4:55 AM UTC

lgleason wrote: post #223

marshray wrote: post #205

Earlier quoted context omitted.

http://blog.phusion.nl/2013/01/03/rails-sql-injection-vulner... Here are some good and experienced Rails developers who apparently had no idea that Rails would automagically suck in XML and YAML and turn it into symbols instead of strings. Clearly they aren't the only ones who didn't "understand the framework" or we wouldn't have gone a week with the impression that CVE-2012-5664 was only exploitable in specific circ…

That's not my point.... I made the "understand the framework" statement in response to some mistakes I have seen introduced by sloppy dev's on some rails projects I have worked on...That obviously wasn't the case here....... If security is important you should periodically try to hack the system and consider incorporating automated penetration testing software against your application. I haven't had a need to go this…

I'm just saying Ruby is good at enabling DWIM and Rails has taken it and run with it to the point of magical thinking.

It's very hard for an app developer to test for vulnerabilities such as this one which seem to involve a combination of contributory factors. When magical stuff is constantly willing to help the app developer out in the background, it's very difficult to get a handle on what our true attack surface is.

Re: Multiple vulnerabilities in parameter parsing in Action Pack

#236

Post by lambda » Wed, Jan 09, 2013, 5:03 AM UTC

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.

Less magic.

The more magic, unexpected behavior you have when parsing untrusted input, the more likely you are to have security holes.

Instead of building up some complex object based on untrusted input, the author of the application should specify the values and types expected, and the parser should parse those and nothing more. This would lead to much simpler code paths, as the user never has an object that has unexpected keys, values, behaviors, etc. Don't parse the object using complex, general purpose code, then hand the user an object that they have to treat specially; if their form only expects 5 values of given types, then parse only those values and those types.

The problem is, all of this kind of magic is at the very heart of what Rails is. I don't know if you could eliminate it all and still have Rails be Rails.

Re: Multiple vulnerabilities in parameter parsing in Action Pack

#237

Post by lgleason » Wed, Jan 09, 2013, 5:12 AM UTC

marshray wrote: post #235

lgleason wrote: post #223

Earlier quoted context omitted.

That's not my point.... I made the "understand the framework" statement in response to some mistakes I have seen introduced by sloppy dev's on some rails projects I have worked on...That obviously wasn't the case here....... If security is important you should periodically try to hack the system and consider incorporating automated penetration testing software against your application. I haven't had a need to go this…

I'm just saying Ruby is good at enabling DWIM and Rails has taken it and run with it to the point of magical thinking. It's very hard for an app developer to test for vulnerabilities such as this one which seem to involve a combination of contributory factors. When magical stuff is constantly willing to help the app developer out in the background, it's very difficult to get a handle on what our true attack surface i…

Rails has definitely started to get complex, which is why many have chosen to go towards the simplicity of Sinatra, Rack etc.. Any time a framework get's complex this happens.

Look at big data and AI. There are loads of permutations. How do you prevent stuff from just happening? How do you make sure that things are correct etc.? Trust me I would love to do TDD on an AI / big data analysis project. But the reality is that no-one has figured out how to reliably test things....so TDD is not the right tool at this point. But there is also the potential to introduce vulnerabilities. That doesn't mean I am not going to use AI or do big data.

It's always a balance between tighter security/less complexity, or more complexity and less security etc...obviously there are other factors as well, but my point is to choose the right tool for the job.....sometimes it is Rails, and sometimes not......

And beyond that give the Rails team kudos for a taking care of things like this when they do find them.

Re: Multiple vulnerabilities in parameter parsing in Action Pack

#238

Post by martinced » Wed, Jan 09, 2013, 5:14 AM UTC

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 Tomcat in 2011 too, so we're not doing anything wrong here".

And start coding (and documenting) to higher standards.

Re: Multiple vulnerabilities in parameter parsing in Action Pack

#239

Post by martinced » Wed, Jan 09, 2013, 5:19 AM UTC

danso wrote: post #88

sdoowpilihp wrote: post #34

Can anyone with a more intimate knowledge of the inner workings of Ruby on Rails speak to how detrimental this exploit is in practice? I seem to recall a fair number of people feeling the SQL injection exploit from a few days ago was being blown out of proportion and I was wondering how this particular exploit stacks up against it.

I'm not going to say "told you so" because I said nothing and I'm just a layman in this...but when people were pointing out last week that the bug was "overblown" I had wondered if they were underestimating the tendency for such vulnerable patterns to propagate. The mechanisms that let even an edge case in are not always isolated.

Oh I'm saying "told you so". Since years and years.

The real problem is the very mentality of the people who downplay security issues, always saying "this is not a serious issue" (or, worse, saying "but language xxx / framework yyy" suffers from issues too, it's how the world works).

That mentality is the reason why such exploits do exist in the first place. Security is nearly always an afterthought.

The most braindead argument being: "My goal is to sell xxx, not to have an unbreakable server".

Once you read that one, you know you have reached the low of the low.

Re: Multiple vulnerabilities in parameter parsing in Action Pack

#240

Post by marshray » Wed, Jan 09, 2013, 5:27 AM UTC

lgleason wrote: post #237

marshray wrote: post #235

Earlier quoted context omitted.

I'm just saying Ruby is good at enabling DWIM and Rails has taken it and run with it to the point of magical thinking. It's very hard for an app developer to test for vulnerabilities such as this one which seem to involve a combination of contributory factors. When magical stuff is constantly willing to help the app developer out in the background, it's very difficult to get a handle on what our true attack surface i…

Rails has definitely started to get complex, which is why many have chosen to go towards the simplicity of Sinatra, Rack etc.. Any time a framework get's complex this happens. Look at big data and AI. There are loads of permutations. How do you prevent stuff from just happening? How do you make sure that things are correct etc.? Trust me I would love to do TDD on an AI / big data analysis project. But the reality is…

Let us agree in giving the Rails secuity team many well-deserved thanks!

We on the sidelines primarily criticise as a stage of our shock and grief. That the patches keep flowing is unsettling in the short term but reassuring in the long term.

Thanks again everyone who dropped everything and worked so hard to get this set of fixes out!