6 ms·
Heroku: Resolved Security Vulnerability
- dholowiski 16y agoHoly crap i have a pile of passwords to change now.
- teich 16y agoOfficial Status Blog Post: http://status.heroku.com/incident/115 http://status.heroku.com/incident/115
- codemonger 16y agonot cool, but figures.
- cduruk 16y agoThe discoverer of the vulnerability also wrote a blog post about it. Blog post: http://daverecycles.com/post/2858880862/heroku-hacked-dissecting-herokus-critical-security http://daverecycles.com/post/2858880862/heroku-hacked-dissec... HN Discussion: http://news.ycombinator.com/item?id=2128175 http://news.ycombinator.com/item?id=2128175 Disclaimer: I know David E. Chen personally from college.
- catch23 16y agoSeems like something like this could have been easily prevented early on using bsd jails or linux vservers for proper sandboxes.
- lfittl 16y agoWhat I really don't understand - why aren't they using virtualization? (e.g. OpenVZ)
- tptacek 16y agoBecause it's very slow compared to application-layer segregation.
- martinp 16y agoThere are different kinds of virtualization. OS-level virtualization like Linux-VServer and FreeBSD jails have little to no overhead while being very secure.
- tptacek 16y agoJails aren't virtualization. I don't know why they don't use jails, but the answer on "virtualization" seems straightforward.
- martinp 16y agoYes, 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 http://en.wikipedia.org/wiki/OS-level_virtualization
- mattyb 16y agoRemember this? http://news.ycombinator.com/item?id=362082 http://news.ycombinator.com/item?id=362082 Do you still think that's a good idea?
- tptacek 16y agoI don't understand what point you're trying to make (also, how'd you come up with THIS particular comment, from 800 days ago?).
- mattyb 16y agoIt was a serious question, I didn't mean to sound snarky. I'm asking if you think it'd be a better idea (from a security perspective) to keep customers on separate VMs. My understanding of this vulnerability is that it relies on several customers sharing a filesystem; if Heroku simply spawned a new instance (they're already running on EC2) for each customer, wouldn't this be mitigated? Also, I was looking up info on Pivotal Tracker yesterday (after the announcement that they were going paid) and saw your comment.
- grey_hatte 16y agoI wonder how many black hats just cringed as they lost the ability to invisibly harvest the contents of heroku app databases. And I wonder how many of those databases remain vulnerable because of previously exposed credentials.
- rst 16y agoSummary 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 16y agoThe 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 16y agoI 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 16y agoCan 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.
- 16y ago
- tlrobinson 16y agoHmm, I thought Heroku used chroot jails to prevent apps from seeing each other. No?