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

31–40 of 183 posts

Re: What The Rails Security Issue Means For Your Startup

#31

Post by jroes »

tomjen3 wrote: post #22
purephase wrote: post #11

Earlier quoted context omitted.

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.

I'm willing to bet if you put someone like benmmurphy, ptacek, or homakov in your codebase he'll have you begging for a web framework in hours.

Re: What The Rails Security Issue Means For Your Startup

#32

Post by SilasX »

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 issue was reported to RubyGems multiple times and they did nothing.

Er, there would have been trouble on that end too ...

http://news.ycombinator.com/item?id=5139583

Re: What The Rails Security Issue Means For Your Startup

#33

Post by dos1 »

tomjen3 wrote: post #20
purephase wrote: post #7

Earlier quoted context omitted.

Different issue altogether. It was mass-assignment wherein the default Rails config did not have the whitelist enabled by default. The howto is here: http://homakov.blogspot.ca/2012/03/how-to.html

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.

Re: What The Rails Security Issue Means For Your Startup

#34

Post by patio11 »

ontoillogical wrote: post #28
patio11 wrote: post #21

Earlier quoted context omitted.

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 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 those three into remote code execution, the substantial work involved in producing that PoC code -- finding the vulnerable classes which ship with Rails, demonstrating how to get data from where the user controls it into the far-inside-the-framework bits where Rails might actually evaluate YAML, etc etc -- immediately starts suggesting lots of other fun ways to use variants of that trick.

Re: What The Rails Security Issue Means For Your Startup

#36

Post by netshade »

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…

Speaking to the first portion of your complaint, I remember coming across that particular feature of YAML years ago, and being surprised at how odd it was that it was present. I shrugged it off because (at the time), I considered YAML to be something that simply would not enter the serialize / deserialize phase of incoming requests. Ignorance of all the frameworks actions on my part, and further ignorance to not think of the security effects of that particular feature, certainly. I would presume that I am not the only in that situation.

You're definitely right that the security reports should be handled better. I hope that this whole situation results in a better security culture in the Ruby community.

Regarding your tone ("intellectually dishonest", "trained monkey", "systemic engineering incompetence pervades an entire language community"), it's a bit of hyperbole and active trolling. You are certainly right in many of your points, and you are certainly coming off as a jerk. It may not be as cathartic for you, but I'd suggest toning it down to "reasonable human being" level in the future.

Re: What The Rails Security Issue Means For Your Startup

#37

Post by static_typed »

As much as I was a fan of developing Ruby apps, I was constantly shocked by the lack of engineering, security concern, stability of API, basically serious software engineering within the community.

It would be good if all this was a clarion call to the Ruby community to improve things holistically, rather than the current trend of band-aid fixes they seem to apply.

Re: What The Rails Security Issue Means For Your Startup

#38

Post by pifflesnort »

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…

> You might have said "Yes, I am aware of all these three things.

An experienced engineer ought to have said "this is a perfect storm, and it is wrong that YAML can instantiate objects from any class, and there will be a vulnerability here".

The reason such an engineer ought to say this is because 1) In general terms, it should be self-evident that any system built on riding the edge of risk will fail, and 2) We have countless examples over decades of this exact issue occurring repeatedly.

If you need a PoC to understand the severity of such an issue, you do not have the proper engineering mindset to be writing secure code. This was a lesson much of the industry learned in the 90s, where it was necessary to provide a PoC before many developers would take action on an issue.

Re: What The Rails Security Issue Means For Your Startup

#39

Post by boonedocks »

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.

I'm not sure of the best way to go about it, but if all the dependency gems are also on Github, a script might be able to pull the SHAs from the right version of each dependency and return the proper entries for a Gemfile.

Re: What The Rails Security Issue Means For Your Startup

#40

Post by purephase »

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.

Whitelisting is what Rails did to get around the mass assignment issue. It was solved for awhile, it just was not the default configuration setting.

Whitelisting is what the rubygems folks are doing to work around this problem until a better implementation is put in-place in the YAML parser.

Generally, it is a better solution but it is more difficult and can break a lot of dependencies if not implemented correctly.

Post reply on HN