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

What The Rails Security Issue Means For Your Startup

kalzumeus.com

Post reply on HN
Print view View original

171–180 of 183 posts

Re: What The Rails Security Issue Means For Your Startup

#171

Post by mnarayan01 »

makomk wrote: post #167
mnarayan01 wrote: post #136

Earlier quoted context omitted.

Here's the thing. You can not load YAML with attackable data. Period. If you do, you have to assume bad things are going to happen. The fact that psych calls []=(key, val) on instantiated objects in combination with ActionController::Routing::RouteSet::NamedRouteCollection calling eval on the key made for a particularly easy drive-by attack on a huge range of deployments, but even without the []=, there are still ple…

You're describing the previous Ruby on Rails vulnerability. The latest one involved them deliberately using the YAML parser to parse untrusted JSON data. Also, the RubyGems compromise was a result of them parsing gem metadata represented using YAML - since the metadata is YAML you pretty much have to use a YAML parser to parse it.

Using YAML to parse JSON was obviously non-optimal, which is (presumably) why Rails stopped doing it in 3.1 (thus the vulnerability your refer to is only present in 3.0 and 2.x).

W.r.t RubyGems, I hear what you're saying, but that doesn't mean there's a bug in psych. Even the feature request of adding a safe_load option strikes me as problematic...either you're limiting the markup to json with comments, or you'd have to name the option something like sort_of_safe_load.

Re: What The Rails Security Issue Means For Your Startup

#172

Post by gthbriem »

rmc wrote: post #166
NelsonMinar wrote: post #27

Earlier quoted context omitted.

What is crazy to me is everyone has had this bug, and learned from it, and fixed it. Why has it taken so long for Rails? Java has this bug; you can't deserialize untrusted input without a lot of work. Python has this bug; you can't unpickle untrusted input. Bad Javascript JSON parsers that just call eval() have this bug. It's not a complicated concept; you can't treat untrusted user input as code to execute. How'd th…

Python has this bug; you can't unpickle untrusted input I thought you could unpickle untrusted input in Python? Sure there's a great big red warning message on the documentation, and hence it's currently rare for people to do it, but it is technically allowed, right?

Sure, this is “can't” in the sense “must not”.

Re: What The Rails Security Issue Means For Your Startup

#173

Post by martinced »

Code execution while deserializating / parsing data is my first and uttermost concern. Nowadays I'm in Clojure land and it's still not entirely clear as to what I can and cannot do and what the language as to offer me so that data doesn't contain rogue code that is going to be executed.

In Common Lisp, for example, as far as I know you can set a flag so that the reader is set to "no evaluation ever" (if I understand things correctly) and, hence, if you're not using eval yourself specifically, nothing is ever going to be evaluated.

But how would that work in Clojure? And what about other languages? Ruby? Haskell? Java? C#?

I think the ability to execute code became the most important security issue (more than buffer overflow/overrun which can now be prevented --even sometimes provably impossible to happen thanks to theorem provers).

More thoughts should be put into explaining how/when a language / API can execute code and how it should/can be used to prevent such a thing from happening.

Re: What The Rails Security Issue Means For Your Startup

#174

Post by martinced »

pifflesnort wrote: post #3

The "everybody has bugs" response is intellectually dishonest. Yes, everybody has bugs, but most people's bugs aren't an intentional feature that a trained monkey ought to have known was a bad idea. - Someone implemented a YAML parser that executed code. This should have been obviously wrong to them, but it wasn't. - Thousands of ostensible developers used this parser, saw the fact that it could deserialize more than…

"The "everybody has bugs" response is intellectually dishonest."

Indeed. It's the "fallacy of gray". Nothing is black or white, hence everything is gray. Nothing is 100% secure, nothing is 100% insecure, hence everything is "semi-secure": it's bad, but not too bad, because every language / API / server can be attacked.

You've effectively substituted a black/white dichotomy with something even worse: instead of having only two options (black or white), you now only have one: gray.

It is probably one of the most intellectually dishonest logical fallacy of all times and we keep seeing it more and more.

It's really concerning.

Re: What The Rails Security Issue Means For Your Startup

#175

Post by rmc »

benmmurphy wrote: post #137
homakov wrote: post #131

Earlier quoted context omitted.

>but it sucks that CSRF bug becomes RCE bug :( you just said it - it cant be exploited via CSRF. Because you cannot set header. NO EXPLOIT FOR LOCALHOST:3000 calm down

i actually lied :) there is #from_xml so if you were doing Hash.from_xml(params[:trololol]) or Post.from_xml(params[:lols]) then you would be vulnerable to localhost:3000 attack. but I don't think there is generic attack it would have to be application specific.

Yet.

Re: What The Rails Security Issue Means For Your Startup

#176

Post by martinced »

firemanx wrote: post #46

I think the recent Rails, Java, RubyGems and other vulnerability issues have been an absolute boon to the industry. And not just for the increased business I think most security consultants are going to be seeing. The exploits have happened in ways that have exposed and hammered home the myriad places many applications expose unexpected side channels and larger attack surfaces than you'd think. These issues have open…

+1

I was going to post something similar. Also we often see people insulting others when they post exploits too early or describe exploits in depth too early. Posting stuff like: "You're an .ssh.le, wait a few days before posting that".

I don't think so. I think exploits should be publicly posted as soon as possible and affecting as many people as people. Maybe even damaging exploits, actively deleting users data or servers data.

The bigger the havoc, the sooner the entire industry is going to realize security is a very real concern.

People are still considering buffer overflow, SQL injection, query parameters objects instantiation through deserialization exploits, etc. to be "normal" because "everybody creates bugs" and "a lot of bugs can be exploited".

I think it's the wrong mindset. Security if of uttermost importance and should be thought of from the start.

For example I'm amazed by the recent seL4 microkernel which makes buffer overflow provably impossible (inside the microkernel) or even the Java VM (the JVM) which makes buffer overflow in Java code impossible. It's not perfect (we've seen lots of major Java exploits, but zero were buffer overrun/overflow in Java code... Some in 3rd party C libs, but zero in Java code. Some other Java exploits too of course, but zero buffer overrun/overflow).

So security exploits are not a fatality.

All we need is people, from the very start, to conceive systems more resilients to attacks.

The more attacks, the more exploits, the more bad reputation and shame on clueless developers, the better.

I actually start to love these exploits, because they fuel healthy research by the white-hat community.

And one day we'll have more secure microkernels, more secure OSes, more secure VMs, more secure protocols, etc.

Let them security exploits come.

Re: What The Rails Security Issue Means For Your Startup

#177

Post by hilko »

purephase wrote: post #11
pifflesnort wrote: post #8

Earlier quoted context omitted.

> Is that seriously what happened? Surprisingly, yes: https://github.com/tenderlove/psych/issues/119 And the RubyGems folks are trying to handle this with whitelisting specific classes that the YAML parsing will still be allowed to instantiate: https://github.com/rubygems/rubygems.org/pull/516/files

As a temporary workaround until Psych is updated. At least that's how I read it. We can either sit around throwing stones at them or pull up our sleeves and help. I'm not sure what there is to gain with the former.

I agree with the sentiment to help and not just throw stones, but I think all the outrage and whatnot is very useful: it makes this kind of stuff less likely to happen.

Re: What The Rails Security Issue Means For Your Startup

#178

Post by revelation »

phil wrote: post #161
revelation wrote: post #148

Earlier quoted context omitted.

What you are looking for is not "OO language", but "dynamic interpreted language". In a traditionally compiled OO language like C++, classes cease to exist after compilation; there is no fully generic way to instantiate an object of a class by data determined at runtime. So this whole concept of deserializing to whatever the protocol specifies goes completely out of the door.

"Interpreted" is too restrictive. For example, Objective C provides NSClassFromString().

One could argue that since every call goes through a runtime messaging framework, Objective C is really just an interpreted language with pre-JITed function bodies.

Re: What The Rails Security Issue Means For Your Startup

#179

Post by tomjen3 »

randomdata wrote: post #57
tomjen3 wrote: post #22

Earlier quoted context omitted.

Rails needs to die. It is super nice to code in (for a certain class of problems, ie. CRUD apps) and the language is awesome but it is too big and insecure to use.

Anything you implement to replace the functionality missed by not using Rails will be, statistically, just as insecure. Arguably, even more-so because you will no doubt lack the peer review a large project like Rails benefits from.

I don't think so. Rails has to cover all cases, you just have to code the few cases that you actually use.

And even if you get it wrong, you get it wrong in a different way. That might mean that you are technically more at risk, but so long as the attack is focused on getting as many targets as possible, rather than you explicitly, then that is arguably a great strategy: the cost of adapting an already existing attack to target a novel target is going to be astronomically high, versus using an already existing vulnability. If you are refining neuclear material for Iran, you are going to need all the protection you can get; if you are just another start-up you just need not to be vulneable to the latest drive-by exploit.

Re: What The Rails Security Issue Means For Your Startup

#180

Post by tomjen3 »

dos1 wrote: post #33
tomjen3 wrote: post #20

Earlier quoted context omitted.

Actually it is the same issue as basically all other security issues in web programming (attack on crypto aside): Failure to blacklist non-conforming input. Really, it is that simple and that complicated.

Wouldn't whitelisting conforming input be a better approach? I realize it may be more difficult, but wouldn't that be more secure? Edit: I'm genuinely interested - I always try and whitelist things when I'm building software. Although I have next to no background when it comes to security in particular.

Stupid me. I meant to write whitelisting.

Yes, you are absolutely right.

Post reply on HN