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

21–30 of 183 posts

Re: What The Rails Security Issue Means For Your Startup

#21

Post by patio11 »

ontoillogical wrote: post #13

> The recent bugs were, contrary to some reporting, not particularly trivial to spot. They’re being found at breakneck pace right now precisely because they required substantial new security technology to actually exploit, and that new technology has unlocked an exciting new frontier in vulnerability research. What technology is he talking about here?

Basically, a new way to combine things we already know about. Like, you might have already unlocked "stone axe", "vines", and "dry wood", but given those three primitives I can show you a novel way of combining them that repeatable produces fire. We know have a fun and exciting new way to use commonly-accepted-general-purpose-programming-tools to blow stuff up, and are iterating -- rapidly -- on bringing other previously-assumed-safe constructs into the "blows stuff up" zone of knowledge.

Re: What The Rails Security Issue Means For Your Startup

#22

Post by tomjen3 »

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.

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.

Re: What The Rails Security Issue Means For Your Startup

#23

Post by tomjen3 »

ontoillogical wrote: post #13

> The recent bugs were, contrary to some reporting, not particularly trivial to spot. They’re being found at breakneck pace right now precisely because they required substantial new security technology to actually exploit, and that new technology has unlocked an exciting new frontier in vulnerability research. What technology is he talking about here?

YAML automatic code execution.

Previously you had to send something to rails and find a way to cause rails to execute that. Not so easy.

Now? You just have to send some YAML to rails.

Re: What The Rails Security Issue Means For Your Startup

#24

Post by josephlord »

rlpb wrote: post #19

You do all deploy from your own cache of all the gems you depend on, right? No? Why not?

That only helps you with availability though doesn't it? You are just as likely to have pulled backdoored files and cached them as to get backdoored files directly. Also at some point you need to update.

So I think it only helps if you are likely to need to deploy additional/alternative servers of the same versions. For significant deployed services this makes sense but if you are only in development/testing or using a service like Heroku it doesn't really help you very much does it?

Re: What The Rails Security Issue Means For Your Startup

#25

Post by cheald »

ontoillogical wrote: post #13

> The recent bugs were, contrary to some reporting, not particularly trivial to spot. They’re being found at breakneck pace right now precisely because they required substantial new security technology to actually exploit, and that new technology has unlocked an exciting new frontier in vulnerability research. What technology is he talking about here?

That seemed like an ill-spoken line. What's happening here is that a row of dominoes is falling because of one class of vulnerability. The publication of the YAML hole has caused people to search for a) exploit vectors for that hole, and b) similar classes of exploits that are now much more obvious due to the knowledge of the original hole.

I think that to suggest that this bug could not have been found before is wrong, but the reason we're seeing such a cascade is because security almost never happens in a bubble.

Re: What The Rails Security Issue Means For Your Startup

#26

Post by pifflesnort »

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…

> 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 off Java in the browser for 4+ years, and this is also why Spring shouldn't have implemented such code.

> It's hard stuff, by nature.

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.

> Do you have a citation for this? What particular bug in the parser are you referring to?

http://github.com/tenderlove/psych/issues/119

Re: What The Rails Security Issue Means For Your Startup

#27

Post by NelsonMinar »

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 the YAML developers miss it?

Re: What The Rails Security Issue Means For Your Startup

#28

Post by ontoillogical »

patio11 wrote: post #21
ontoillogical wrote: post #13

> The recent bugs were, contrary to some reporting, not particularly trivial to spot. They’re being found at breakneck pace right now precisely because they required substantial new security technology to actually exploit, and that new technology has unlocked an exciting new frontier in vulnerability research. What technology is he talking about here?

Basically, a new way to combine things we already know about. Like, you might have already unlocked "stone axe", "vines", and "dry wood", but given those three primitives I can show you a novel way of combining them that repeatable produces fire. We know have a fun and exciting new way to use commonly-accepted-general-purpose-programming-tools to blow stuff up, and are iterating -- rapidly -- on bringing other previo…

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 are using in some of the PoCs?

Re: What The Rails Security Issue Means For Your Startup

#29

Post by rst »

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…

Spring isn't the only widely-used Java framework that's had these problems. The Struts developers put a general-purpose interpreter (OGNL) in their parameter parsing pipeline, and thought they'd kept things safe by blacklisting dangerous syntax.

Wackiness ensued: http://blog.o0o.nu/2010/07/cve-2010-1870-struts2xwork-remote...

It would obviously be unfair to claim on this basis, or the recent problems with the Java browser plugin, that the "entire Java language community" has a bad attitude on security matters. Communities are big, each of them has a range of attitudes within it, and most importantly --- regardless of attitude --- sooner or later, everyone screws up.

Re: What The Rails Security Issue Means For Your Startup

#30

Post by excid3 »

purephase wrote: post #10
excid3 wrote: post #6

Earlier quoted context omitted.

Regarding #2, you could use gems from the github repositories (just specify the tag) instead of relying on gems hosted on RubyGems. Obviously then it is up to you to verify everything, including that you're using the right versions and what not.

Probably not safe enough as most of them probably list external dependencies that will fall back to rubygems.

Good point.
Post reply on HN