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

241–250 of 294 posts

Re: Multiple vulnerabilities in parameter parsing in Action Pack

#241

Post by drstewart »

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 still believe you may not understand the difference between a language and a framework.

Re: Multiple vulnerabilities in parameter parsing in Action Pack

#242

Post by steveklabnik »

lgleason wrote: post #225
smackfu wrote: post #174

Earlier quoted context omitted.

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

I thought some come of the core committers had their work sponsored by their employers.

Aaron is the only person on core who is paid to work on Rails. (Among other things.)

I am a committer, and part of my job is to work on open source. Ish.

Other than that, it's everyone else's spare time, IIRC.

Re: Multiple vulnerabilities in parameter parsing in Action Pack

#243

Post by vinhboy »

tptacek wrote: post #224
vinhboy wrote: post #220

Earlier quoted context omitted.

Wait, what? What if the app does not parse ANY user provided XML or YAML at all?

That does not matter.

Holy cow. I just figured out how to send the payload. This thing is seriously bad news.

I still haven't figured out an attack vector yet, but least I now know that my patches are working!

Re: Multiple vulnerabilities in parameter parsing in Action Pack

#244

Post by tedunangst »

drstewart wrote: post #241
alexanderh wrote: post #231

Earlier quoted context omitted.

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 still believe you may not understand the difference between a language and a framework.

The distinction is rather academic with ruby and rails. 90% of the answers to "how do I do this in ruby" on forums are actually "how to do this with rails" answers, but they never mention that little detail, because who'd ever write a ruby program without rails, right? Trying to find straight ruby answers is annoying as hell.

Re: Multiple vulnerabilities in parameter parsing in Action Pack

#246

Post by headius »

Argorak wrote: post #157
willvarfar wrote: post #141

Why doesn't Ruby (and Python and all other languages) have Perl's tainting built in and always running? I'm not advocating it as the only security mechanism, but rather as another barrier to be overcome just like address-space-randomisation, data-exection prevention and all the rest... (Haven't Google recently shared a valgrind-lite runtime bounds checker which is being incorporated into GCC etc? Might lead the way o…

MRI has tainting through SAFE, but its generally considered problematic and might give a false sense of security. MRI and Rubinius don't implement it.

You mean JRuby and Rubinius, but yes...it's as flawed as every other blacklisting security mechanism. We mostly don't implement it because, well, "here, add these security checks and tainting propagation to EVERY METHOD IN THE SYSTEM and if you don't do it right, you're totally effed." Sounds great.

Re: Multiple vulnerabilities in parameter parsing in Action Pack

#247

Post by headius »

teyc wrote: post #173
headius wrote: post #145

Earlier quoted context omitted.

Because tainting is an inherently flawed way to do security. Blacklisting capabilities/methods/data always leaves holes behind, and it's nearly impossible to secure a system using tainting alone. Even the Perl folks say it shouldn't be used as a security mechanism...it should be used to help thin out security issues during development and testing. If you want to secure a system...whitelist, don't blacklist.

If the runtime overhead is low, then shouldn't tainting be used in addition to other techniques? ala Defense in depth?

You certainly can do that. You can also add more and more locks to your doors while leaving your windows open.

Re: Multiple vulnerabilities in parameter parsing in Action Pack

#248

Post by lgleason »

steveklabnik wrote: post #242
lgleason wrote: post #225

Earlier quoted context omitted.

I thought some come of the core committers had their work sponsored by their employers.

Aaron is the only person on core who is paid to work on Rails. (Among other things.) I am a committer, and part of my job is to work on open source. Ish. Other than that, it's everyone else's spare time, IIRC.

Wow, that actually gives me more confidence because we have people doing it because they feel passionate about it. Thanks for your hard work....

I've been busy with some other small OS projects (and stuff that pays the bills) but personally feel like I need to try to carve out some time this year to do something to contribute back to Rails.....

Re: Multiple vulnerabilities in parameter parsing in Action Pack

#249

Post by nthj »

lambda wrote: post #236
steveklabnik wrote: post #181

Earlier quoted context omitted.

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

This sounds a lot like strong_parameters, which (I believe) will be the default in Rails 4, and is only a gem install away from Rails 3.2 apps.

https://github.com/rails/strong_parameters

Re: Multiple vulnerabilities in parameter parsing in Action Pack

#250

Post by yannicks »

wglb wrote: post #222
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…

So far as I can tell, there are a seriously large number of people paid to work on Java. The security record of Java is way worse than Ruby. I can tell you that "security" is a topic that, unless handled carefully, will make anyone's eyes glaze over.

Remember when release cycles where short in Java? Me neither
Post reply on HN