David E. Chen: Discovering the Heroku Vulnerability | Hacker News Reader

David E. Chen: Discovering the Heroku Vulnerability

daverecycles.com

108 pointsdaverecycles10 comments

I'm at least pleased with the way they handled the vulnerability. They seem to be making preventative changes for the future which is the main thing.

As much as I'd like everyone to be diligent about security as David suggests, I don't think it's going to happen. Developers aren't security or admin experts but they (me included) want a way to deploy apps without it being a major hassle. Handing off security to the provider is one of the big reason there are > 100K apps on Heroku, and it's a calculated cost/risk tradeoff.

There needs to be a reality check at some point, however.

A company's needs might not be in tune with Heroku's general security policy. If you're creating an app that handles personal information, then I hope to god that your developer/ops guys are security minded.

This particular vulnerability is quite embarrassing, however: separation of environments should at least be a given on Heroku.

Heroku should have filtered other processes out of view that were related to other user's dynos. I think they will fix that.

It was interesting to read how the author figured it out, and his point that he could run a bunch of reapers to steal the information.

Now, if the IT guy running Herkous operations has his hat on straight he will notice the change in bandwidth patterns (higher upload following a heroku push) from the reapers, which is what the Heroku press release alluded to.

Generally, to benefit maliciously you would have to be watching the content without downloading it ("by hand" if you will) and then find something that was worth the effort.

Now that Dynos have more time to be considered in a different light, design changes will at least make the same "lottery watch dog" effect harder to achieve than just lurking on node.

In theory it shouldn't matter whether my security expertise is in-house or I pay some external party to provide it, right? The usual argument for economies of scale also applies - it's beneficial to have the platform provider manage security for the customers. I think the problem is that Heroku's (and most other providers') promise of security is nice in theory, but in practice they carry no responsibility if anything goes wrong.

I agree that it's important to make sure the provider's security policy is sufficient for your needs in the first place, however.

In theory it shouldn't matter whether my security expertise is in-house or I pay some external party to provide it, right?

You are not paying an external party to come by and secure all your servers/applications — you are paying for a service which require you to share a lot of your data with a third party.

The usual argument for economies of scale also applies

But the bigger the third party you outsource to is, the more people will try to hack it.

Which platform was this?

"For example, one Node.js platform provider that has been in the news recently was hacked in the past few days and all of their user databases were deleted. The reason why? They accidentally published their database password on GitHub. Oops."

This doesn't really surprise me, considering everyone and their mother is currently building "Heroku for Python/Node.js/[hot technology]".

NodeFu.

This sort of hosting is basically no different than a typical 'shared host'. Why is there no 'heroku for PHP'? Oh... because those have been around for 8 years+ and are called 'shared hosts with Apache/PH/MySQL'.

I've looked around on a couple of hosts, 1and1 and I think he.net and found that it was quite possible to go looking around in other users accounts through the shell.

I'll stick with VPSs and dedicated servers.

http://phpfog.com/ is like heroku for PHP without the shared host.

Ugh. And to think I was worried about the implications of user privilege exploits on Heroku (well, I still am). Turns out there was no need to be so fancy!

Reply on news.ycombinator.com