
Heroku: Resolved Security Vulnerability				  - bjonathan
http://pastebin.com/p3XrtdEa
======
rst
Summary of the vuln, from the original post: Heroku was relying on unguessable
filenames to keep processes associated from one app from reading files
containing the config files and source code of another app. However, the
random portion of those filenames was showing up in the output of 'ps' as run
from (I think) 'heroku console'.

The upshot was that the filenames were easily guessable, and their contents
(config files and source code of the app) easily accessible.

So, if you've had a heroku app running between December 28 and January 17,
your config files are possibly compromised.

(The scary part, to me, is what a malicious party could have done with access
to somebody else's database.yml, but I haven't seen any writeup specifically
address that point.)

~~~
tptacek
The filenames weren't so much easily guessable as a change Heroku made last
month accidentally exposed files. Relying on unpredictable strings isn't a
fundamentally bad architecture; it's not an exaggeration to say that the whole
web depends on that design.

My recommendation to Heroku might start with auditing every Heroku tool to
make sure it calls "setproctitle".

~~~
rst
I meant to say that the filenames were easily guessable _after_ the random
strings were exposed by 'ps'.

Relying on unpredictable strings works fine, so long as you keep them away
from prying eyes. But that requires attention to detail, and can get harder
over time (witness, say, Firesheep, which made it a whole lot easier to hide
"secret" login cookies than it used to be).

~~~
tptacek
Can I just say that "secrets" sent over bare HTTP aren't secret, and that even
before Firesheep, nobody really thought they were hard to find? I love what
Firesheep did to popularize that problem, but it was an old, very widely-
exploited problem.

~~~
rst
Sure, but Firesheep made it possible to exploit it without even "script-
kiddie" level skills. No easier in principle, perhaps, but easier in practice.

~~~
gfodor
The point is the type of security scenario being talked about here is wildly
different than the one made simpler to exploit by Firesheep. This was not
security through obscurity. If your servers are configured correctly,
unguessible filenames are just fine from a security perspective, at least as
secure as passwords.

------
cduruk
The discoverer of the vulnerability also wrote a blog post about it.

Blog post: [http://daverecycles.com/post/2858880862/heroku-hacked-
dissec...](http://daverecycles.com/post/2858880862/heroku-hacked-dissecting-
herokus-critical-security)

HN Discussion: <http://news.ycombinator.com/item?id=2128175>

Disclaimer: I know David E. Chen personally from college.

------
teich
Official Status Blog Post: <http://status.heroku.com/incident/115>

------
catch23
Seems like something like this could have been easily prevented early on using
bsd jails or linux vservers for proper sandboxes.

------
lfittl
What I really don't understand - why aren't they using virtualization? (e.g.
OpenVZ)

~~~
tptacek
Because it's very slow compared to application-layer segregation.

~~~
martinp
There are different kinds of virtualization. OS-level virtualization like
Linux-VServer and FreeBSD jails have little to no overhead while being very
secure.

~~~
tptacek
Jails aren't virtualization. I don't know why they don't use jails, but the
answer on "virtualization" seems straightforward.

~~~
martinp
Yes, I was surprised too. I've never used the word "virtualization" when
refering to jails and VServer, but Wikipedia apparently refers to it as
"Operating system-level virtualization".

<http://en.wikipedia.org/wiki/OS-level_virtualization>

------
tlrobinson
Hmm, I thought Heroku used chroot jails to prevent apps from seeing each
other. No?

------
dholowiski
Holy crap i have a pile of passwords to change now.

------
codemonger
not cool, but figures.

