What The Rails Security Issue Means For Your Startup • Hacker News Board

Re: What The Rails Security Issue Means For Your Startup

#141

Post by squidsoup » Thu, Jan 31, 2013, 10:19 PM UTC

jaequery wrote: post #67

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.

rails don't need to die, but seeing how ruby devs like bashing other languages, this event seems to me like karma.

Can we please try to avoid making generalisations like this? Yes, the ruby community has some very vocal contributors with very questionable social skills. Please don't assume that all ruby developers are egotistical hipster hackers. The creator or Ruby, Matsumoto Yukihiro is one of the most softly spoken and humble individuals I have encountered in technology. We can all learn by his example.

Re: What The Rails Security Issue Means For Your Startup

#142

Post by steveklabnik » Thu, Jan 31, 2013, 10:39 PM UTC

squidsoup wrote: post #139

steveklabnik wrote: post #98

Earlier quoted context omitted.

I just wrote a blog post: http://words.steveklabnik.com/how-to-not-rely-on-rubygemsorg...

Wasn't aware of bundle --deployment, that's very helpful thank you steve.

Any time! Not enough people are.

Re: What The Rails Security Issue Means For Your Startup

#143

Post by kyllo » Thu, Jan 31, 2013, 10:57 PM UTC

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…

>>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?

>That is astonishingly unlikely to be a net-win for your security.

In the long run, you are probably right. Once this gets fixed, which will probably be soon considering how much attention is on it.

But in the short run, is there anything worse than a vulnerability that allows a remote attacker to automatically detect, penetrate, and execute arbitrary code on your machine? To the point where it's not even safe to run the framework on localhost on your dev box?

Re: What The Rails Security Issue Means For Your Startup

#144

Post by [deleted] » Thu, Jan 31, 2013, 11:40 PM UTC

patio11 wrote: post #77

hawleyal wrote: post #70

FUD much

Hiya, welcome to Hacker News. I'm Patrick and I wrote this article. I run four businesses, three of which are intimately tied to Ruby on Rails, I am a contributor in the community, and I want to see it win. If you believe I am trying to spread fear, uncertainty, or doubt, you are greatly mistaken about my motives. As someone who loves Rails, to someone who presumably likes Rails, it is imperative that you understand…

[deleted]

Re: What The Rails Security Issue Means For Your Startup

#145

Post by eli » Thu, Jan 31, 2013, 11:41 PM UTC

purephase wrote: post #76

mikegirouard wrote: post #50

This quote caught my attention: There are many developers who are not presently active on a Ruby on Rails project who nonetheless have a vulnerable Rails application running on localhost:3000. If they do, eventually, their local machine will be compromised. (Any page on the Internet which serves Javascript can, currently, root your Macbook if it is running an out-of-date Rails on it. No, it does not matter that the I…

Other than ease of setup, I've never understood why you wouldn't develop in the same environment as what you're running in production. Setting up a vm is trivial and allows you to easily open/close access to your application as needed. There is also a lot less headaches once you've decided to move it into production.

I agree 100%... but doing so would not protect you from the security issue being discussed.

Re: What The Rails Security Issue Means For Your Startup

#146

Post by pifflesnort » Thu, Jan 31, 2013, 11:49 PM UTC

jrochkind1 wrote: post #123

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…

> 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 string class should be instantiated. You also do not 'eval' the data to determine which fields to set on the string class.

You instantiate a known String type, and you feed it the string representation as an array of non-executable bytes using a method you specified when writing your code -- NOT a method the data specifies.

The data is not executable. It's an array of untrusted bytes. The string code is executable, and it operates on state: the data.

You repeat this process, feeding the string objects into the list object. At no point do you ask the data what class or code you should run to represent it. Your parsing code dictates what classes to instantiate, and the data is interpreted according to those fixed rules, and your data is never executed.

It should never be possible for data to direct the instantiation of types. The relationship must always occur in the opposite direction, whereby known types dictate how to interpret data.

> I think it was not obvious to a bunch of people who are in retrospect _claiming_ it was obvious to.

Given the preponderance of prior art, this seems unlikely.

Re: What The Rails Security Issue Means For Your Startup

#147

Post by jacquesc » Fri, Feb 01, 2013, 12:01 AM UTC

jmount wrote: post #16

This blindness to how bad YAML was is causing "convention over configuration" to devolve into "security by convention".

you mean "insecurity by convention"?

Re: What The Rails Security Issue Means For Your Startup

#148

Post by revelation » Fri, Feb 01, 2013, 12:27 AM UTC

jrochkind1 wrote: post #123

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…

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

Re: What The Rails Security Issue Means For Your Startup

#149

Post by jammycakes » Fri, Feb 01, 2013, 12:40 AM UTC

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 impression that the Rails ecosystem favours convenience over security, in an Agile Manifesto kind of way (yes, we value the stuff on the right, but we value the stuff on the left even more). One of the attractions of Rails is that it is very easy to get stuff up and running with it, but some of the security exploits that I've seen cropping up recently with it make me pretty worried about it. I get especially concerned when I see SQL injection vulnerabilities in a framework based on an O/R mapper, for instance.

Re: What The Rails Security Issue Means For Your Startup

#150

Post by mgkimsal » Fri, Feb 01, 2013, 12:47 AM UTC

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…

Except, I don't think it's even all that easy. In fact, there was a bit of a meme I remember from last year in which people stated "Rails was never marketed as easy to use!".

I think in 2006/2007, there was a simplicity to the basic "get up and running" aspect, but Rails 3.x+ is a pretty large ecosystem with quite a lot of decision points to educate yourself on to do any sized project beyond 'hello world'.