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

151–160 of 183 posts

Re: What The Rails Security Issue Means For Your Startup

#151

Post by trekkin »

jammycakes wrote: post #149

When I look at the Ruby/Rails community, the word that comes to my mind more than any other is hubris . You see this in things such as security issues being marked as wontfix until they are actively exploited (e.g. the Homakov/GitHub incident), in the attitude that developer cycles are more expensive than CPU cycles, and on a more puerile level in the tendency towards swearing in presentations. I've always had the im…

I have the same impression.

Many start-ups are built by well-meaning people who have no formal CS or even engineering background and thus are somewhat out of touch with what it means to build a robust system. It's natural for people to focus on "what's important" and ignore boundary/edge conditions, while in reality 90% of sound engineering is getting boundary/edge cases right.

And as most of such start-ups use Ruby/Rails due to the easiness of "getting it up and running", and thus they inject the Ruby/Rails ecosystem with this "focus on what's important" mindset, important boundary issues, including security, are neglected.

Re: What The Rails Security Issue Means For Your Startup

#152

Post by djkz »

How feasible would it to have a gem that sits in middleware that would check for possible attacks before the string gets any further and block/share IPs of people fishing for exploits?

I could see it as a service company that shares blacklist info between sites and can even find new exploits from the "bad" requests.

Re: What The Rails Security Issue Means For Your Startup

#153

Post by joseph_cooney »

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…

I guess the difference re: spring is that I don't load my spring configuration via a HTTP connection that is pointed to the internet.

Re: What The Rails Security Issue Means For Your Startup

#154

Post by ianburrell »

patio11 wrote: post #121
kyllo wrote: post #115

Is this YAML vulnerability something that can be patched in relatively short order without Rails itself having to be completely rewritten? Or should I basically just not run Rails on any machine ever anymore, get a different web server, and start implementing my own request routing and ORM without any sort of YAML-parsing magic? >One of my friends who is an actual security researcher has deleted all of his accounts o…

Is this YAML vulnerability something that can be patched in relatively short order without Rails itself having to be completely rewritten? Long story short: There's a variety of things that can be done to mitigate this vulnerability and an active conversation on which is the best option. My go-to suggestion would be having Rails ship with either a non-stdlib YAML serialization/deserialization parser or have it modify…

I think you could make YAML safer and still support most usage by just preventing the deserializer from making any explicit native types. Just support the default types (string, list, map) and ignore all language specific tags. In fact, it looks like the core schema defined in the YAML spec would serve this purpose and would have similar types to JSON.

By making that the default schema, developers would have to explicitly request the dangerous "ruby" schema that makes arbitrary Ruby objects.

Re: What The Rails Security Issue Means For Your Startup

#155

Post by zzzeek »

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…

Parsing is not deserialization. I keep having to say this on all these threads. There should be a giant glowing force field between these two practices.

the particular issue in the Yaml parser is explained pretty well here: http://www.insinuator.net/2013/01/rails-yaml/

Re: What The Rails Security Issue Means For Your Startup

#156

Post by krichman »

patio11 wrote: post #34
ontoillogical wrote: post #28

Earlier quoted context omitted.

I'm not sure I get what you're the analogy to. When I first read your blog post I got the impression that you were saying that the YAML vulnerability were found with some new code scanning technology that lets us find bugs in Rails faster. Or are you just saying discovering the existence of the YAML.load() class of vulnerability is "new security technology?" Or are you talking about the ronin support module people ar…

So if I had told you at Christmas three salient facts: + Some objects are unsafe to instantiate if you don't pick all values you initialize them with very carefully. + YAML can instantiate objects from any class. + Rails uses YAML, in a lot of ways. You might have said "Yes, I am aware of all these three things. Do you have anything important to tell me?" Now, if I demonstrate to you working PoC code which combines t…

I think we should train ourselves to be fully alarmed at "...can instantiate arbitrary...", or just become hypervigilant around synonyms of "any".

Re: What The Rails Security Issue Means For Your Startup

#157

Post by jrochkind1 »

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.

So your conclusion is that dynamically interpreted languages are all insecure?

(You can instantiate objects with classes specified by data in Java too, although Java isn't usually considered exactly dynamicaly interpreted. In fact, there was a very analagous bug in Spring, as mentioned in many places in this comment thread. But anyway, okay, sufficiently dynamically interpreted to allow instantiation of objects with classes chosen at runtime... is the root of the problem, you're suggesting, if everyone just used C++ it would be fine?)

Re: What The Rails Security Issue Means For Your Startup

#158

Post by jrochkind1 »

pifflesnort wrote: post #146
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…

> 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 language, I don't think it's 'intellectual honest' to call allowing de-serialization to data-specified classes "a YAML parser that executed code"--that's being misleading -- or to say that a 'trained monkey should have known it was a bad idea' (allowing de-serialization to arbitrary data-specified classes).

There have been multiple vulnerabilities _just like this_ in other environments, including several in Java (and in major popular Java packages). You could say with all that prior art it ought to have been obvious, but of course you could say that for each of the multiple prior vulnerabilities too. Of course, each time there's even more prior art, and for whatever reason this one finally got enough publicity that maybe this kind of vulnerablity will be common knowledge now.

Re: What The Rails Security Issue Means For Your Startup

#160

Post by ams6110 »

Why don't we have "building codes" for software?

There was a time when anyone who claimed to have the ability could design and build things like bridges and buildings. After enough of them collapsed due to repeated, avoidable mistakes, we said no, you can't do that anymore, you need to be licensed to design and build buildings, and furthermore you have to follow some basic minimum conventions that are proven to work. And you and your firm has to take on personal liability when you certify that your design and construction follows those basic best practices.

Post reply on HN