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

161–170 of 183 posts

Re: What The Rails Security Issue Means For Your Startup

#161

Post by phil »

revelation wrote: post #148
jrochkind1 wrote: post #123

Earlier quoted context omitted.

> Which is why deserializing into executable code is a bad idea, by nature. I'd thought this was well established by now, but apparently it is not I'm not sure that means anything. In an OO language, you are always de-serializing into objects, and objects are always 'executable code'. Hashes and Arrays are executable code too, right? The problem is actually when you allow de-serializing into _arbitrary_ objects of ar…

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().

Re: What The Rails Security Issue Means For Your Startup

#162

Post by pifflesnort »

jrochkind1 wrote: post #158
pifflesnort wrote: post #146

Earlier quoted context omitted.

> I'm not sure that means anything. In an OO language, you are always de-serializing into objects, and objects are always 'executable code'. Hashes and Arrays are executable code too, right? No. You're conflating code and state (which was the problem to begin with!) Let's disassemble parsing a list of strings: When you instantiate the individual string objects, you do not 'eval' the data to allow it to direct which s…

The YAML vulnerability was not from any 'eval' in the YAML library itself, you realize, right? It was from allowing de-serialization to arbitrary classes, when it turned out that some classes had dangerous side-effects merely from instantiation -- including in some cases, 'eval' behavior, yes, but the eval behavior wasn't in YAML, it was in other classes, where it could be triggered by instantiation. To use your lang…

> The YAML vulnerability was not from any 'eval' in the YAML library itself, you realize, right?

> It was from allowing de-serialization to arbitrary classes, when it turned out that some classes had dangerous side-effects merely from instantiation -- including in some cases, 'eval' behavior, yes, but the eval behavior wasn't in YAML, it was in other classes, where it could be triggered by instantiation.

That is eval behavior.

Re: What The Rails Security Issue Means For Your Startup

#163

Post by homakov »

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.

you still needto bypass CSRF protection which is on by default

Re: What The Rails Security Issue Means For Your Startup

#164

Post by InclinedPlane »

jcampbell1 wrote: post #63

It would be interesting if someone wrote a worm that just took all the vulnerable rails apps offline. That way we would have less worry about a million compromised databases. It could be launched from a bookmarklet run from tor browser, and would probably exhaust every ip address in a few days. It would also land whoever did it in jail for a really long time.

Maybe, though with today's legal climate such a thing would be extremely, extremely risky. Gaining unauthorized access to a computer system and exploiting it in a way that potentially causes loss of revenue is not something you want to do lightly even if it might be the right thing to do.

Re: What The Rails Security Issue Means For Your Startup

#166

Post by rmc »

NelsonMinar wrote: post #27
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…

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?

Re: What The Rails Security Issue Means For Your Startup

#167

Post by makomk »

mnarayan01 wrote: post #136
pifflesnort wrote: post #26

Earlier quoted context omitted.

> Any sufficiently advanced serialization standard ... it is often going to get instantiated via calling a zero-argument constructor and then firing a bunch of setter methods. Yes, this is always a bad idea. It's actually in a similar problem space as the constant stream of vulnerabilities in the Java security sandbox (eg, applets); all it takes is one mistake and you lose. And thus, people have been saying to turn o…

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.

Re: What The Rails Security Issue Means For Your Startup

#168

Post by makomk »

gingerlime wrote: post #60
SilasX wrote: post #55

Earlier quoted context omitted.

Really? Has a giant framework like Django had bugs this severe, that allowed data-file parsers to execute arbitrary attacker code?

Nearly. Both piston and tastypie (the two leading frameworks for writing APIs for django) were affected by a very similar code execution vulnerability a while ago. see https://www.djangoproject.com/weblog/2011/nov/01/piston-and-...

Wow. Not sure how they managed to miss the big warnings about yaml.load. Notice, however, that unlike Ruby's YAML parser the Python one does actually have a yaml.safe_load.

Re: What The Rails Security Issue Means For Your Startup

#169

Post by makomk »

patio11 wrote: post #17
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…

Any sufficiently advanced serialization standard will let you serialize/deserialize a wide variety of objects. When J2EE SOAP libraries are passing large amounts of XML back and forth over the wire, it is often going to get instantiated via calling a zero-argument constructor and then firing a bunch of setter methods. As J2EE has learned to its sorrow, there are some good choices for objects to allow people to deseri…

The security fuckup is a lot more simple than that - they fucked up as soon as they opened the door to this kind of complicated interaction by letting untrusted code instantiate arbitrary classes and pass strings of their choice to them. Doesn't matter that they weren't aware of any way this could be exploited, as soon as they let an attacker pass data to random classes that were never designed to accept untrusted input a security disaster was basically inevitable.
Post reply on HN