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

101–110 of 183 posts

Re: What The Rails Security Issue Means For Your Startup

#101

Post by delinka »

btilly wrote: post #100
delinka wrote: post #82

"Any page on the Internet which serves Javascript can, currently, root your Macbook if it is running an out-of-date Rails on it." Why are you running Rails as the root user? This is a bad idea. EDIT: I'm not really into client-side JavaScript these days, but when did browsers start allowing JavaScript to connect to anything except the server from which it came? That would be yet another Bad Idea.

You have bad assumptions. It is all about leveraging access to higher and higher levels. 1. You load the evil JavaScript. 2. That JavaScript adds an image with a URL pointing at localhost:3000. 3. When you load that URL, it causes code execution, causing your computer to open a connection somewhere and start taking instructions. 4. The instructions that arrive includes downloading and installing software that takes a…

You're right. I wasn't seeing all the angles here. But to say this is limited to Macs seems disingenuous.

Re: What The Rails Security Issue Means For Your Startup

#103

Post by steveklabnik »

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…

The initial code for Rubygems was written at Rubyconf '06, if I remember correctly. The Ruby world was very, very different back then. Same with Rails, originally released in '05.

My point is that it's 'taken so long' because all this code is stuff that was written in a totally different time and place. And then was built on top of, after years and years and years.

Now that it _is_ being examined, that's why you see some many advisories. This is a good thing, not a bad one! It's all being looked through and taken care of.

Re: What The Rails Security Issue Means For Your Startup

#104

Post by patio11 »

delinka wrote: post #101
btilly wrote: post #100

Earlier quoted context omitted.

You have bad assumptions. It is all about leveraging access to higher and higher levels. 1. You load the evil JavaScript. 2. That JavaScript adds an image with a URL pointing at localhost:3000. 3. When you load that URL, it causes code execution, causing your computer to open a connection somewhere and start taking instructions. 4. The instructions that arrive includes downloading and installing software that takes a…

You're right. I wasn't seeing all the angles here. But to say this is limited to Macs seems disingenuous.

It is a tongue-in-cheek reference to widespread perceptions about Rails developers' hardware of choice.

Re: What The Rails Security Issue Means For Your Startup

#105

Post by jplewicke »

true_religion wrote: post #92

> The first reported compromise of a production system was in an industry which hit the trifecta of amateurs-at-the-helm, seedy-industry-by-nature, and under-constant-attack. It is imperative that you understand that all Rails applications will eventually be targeted by this and similar attacks, and any vulnerable applications will be owned, regardless of absence of these risk factors. Who was the first reported comp…

I believe Patrick is referring to this Bitcoin exchange being hacked: http://news.ycombinator.com/item?id=5043122 .

Re: What The Rails Security Issue Means For Your Startup

#106

Post by btilly »

delinka wrote: post #101
btilly wrote: post #100

Earlier quoted context omitted.

You have bad assumptions. It is all about leveraging access to higher and higher levels. 1. You load the evil JavaScript. 2. That JavaScript adds an image with a URL pointing at localhost:3000. 3. When you load that URL, it causes code execution, causing your computer to open a connection somewhere and start taking instructions. 4. The instructions that arrive includes downloading and installing software that takes a…

You're right. I wasn't seeing all the angles here. But to say this is limited to Macs seems disingenuous.

He didn't say it was limited to Macs. He gave it as a random example of what could happen.

Re: What The Rails Security Issue Means For Your Startup

#107

Post by digisth »

brown9-2 wrote: post #94
purephase wrote: post #76

Earlier quoted context omitted.

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 don't think this would be any more secure if you were to enable networking on the VM to allow requests from the host machine, which seems like common behavior so that the developer can access the webapp running on the VM from a browser on the host. Or are people developing inside a VM and then testing with a browser on the VM?

You can set up a cloud VM (on Rackspace for example), and then set up your VM's firewall (iptables) to only allowing connections from your test machines (could be your local IP, or the IP address of the test machines from Browserstack or Sauce.) This allows you to keep your dev/staging/prod environments in sync (and allows you to do things like blueprint/image your dev setup to build it elsewhere), decouple your dev from your staging/prod, and allow you to develop from anywhere without needing to carry around the same laptop or rebuild your dev environment on another box - particularly if you use an intermediate system with a static IP so you can reconfigure your firewall whenever needed.

Re: What The Rails Security Issue Means For Your Startup

#110

Post by wglb »

static_typed wrote: post #37

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.

Holistic improvement is good.

Every popular technology goes through this. (C, Java, PHP, etc)

What is encouraging to me is the speed with which these issues get patched in Ruby and Rails, and how the ecosystem is paying attention to these lessons and learning from them.

Contrast this with the length of time recent Java flaws took to get patched (6 months or more) or some of the bugs reported in TOSSA got fixed years later.

The deal is to learn from each of these incidents.

Very few people want to take the trouble to write and use correct programs. We, as an industry, would rather Ship Early and Often. It takes a lot of energy and time endeavor to write correct programs. Very few do that. Three that come to mind are Dijkstra, Knuth, DJB.

Post reply on HN