The Linux kernel exposes lots of interesting information via the
/proc filesystem. For example,
/proc/net/udp expose information about all tcp and udp sessions on the server.
In the usual Linux kernel style, these files are freely readable by all users on the Linux system. This becomes a bit of a problem on a multi-tenant system like Heroku. Heroku deploy many customers apps on each of their Amazon EC2 servers. So if you create an app skeleton, deploy to Heroku and shell out and you can see all the other apps tcp and udp sessions:
$ heroku run console
Running `console` attached to terminal... up, run.1971
irb(main):001:0> system("netstat | grep ESTAB | head -n 10")
tcp 0 0 22d87d80-deb7-415:33113 ip-10-40-86-97.ec:27018 ESTABLISHED
tcp 0 0 22d87d80-deb7-415:57256 ip-10-60-122:postgresql ESTABLISHED
tcp 0 0 22d87d80-deb7-415:59268 domU-12-31-3:postgresql ESTABLISHED
tcp 0 0 22d87d80-deb7-415:38536 collector6.newrelic:www ESTABLISHED
tcp 0 0 22d87d80-deb7-415:54459 ip-10-189-243-92.:27017 ESTABLISHED
tcp 0 0 22d87d80-deb7-415:50495 ip-10-151-25-11.ec:6242 ESTABLISHED
tcp 0 0 22d87d80-deb7-415:53192 ip-10-114-25:postgresql ESTABLISHED
tcp 0 0 22d87d80-deb7-415:47405 22.214.171.124:https ESTABLISHED
tcp 0 0 22d87d80-deb7-415:39011 collector6.newrelic:www ESTABLISHED
tcp 0 0 22d87d80-deb7-415:52237 ip-10-218-31-147.:42002 ESTABLISHED
If the netstat command (or system method) is not available, you can just read and parse the file in Ruby.
It’s an information leak, so I think it is quite low risk but still a hint that Heroku’s process separation still isn’t as strict as one might hope (I still remember David Chen’s pretty shocking discovery back in 2011)
There are a few ways to fix this kind of problem. Mandatory access control systems, like AppArmor can prevent processes reading these files. The Grsecurity security patches have lots of protections against proc based information leaking too, these files included.
I reported my findings to Heroku’s security team back in September 2012. I had some problems getting timely responses at first but after whining on Twitter (in March 2013) I got lots of attention from them (and an apology for lack of response). Complaining on Twitter is a clearly a powerful tool and to be used only wisely; and maybe sometimes when drunk.
Anyway, it seems they had been working hard on this and just failing to update me; it is quite a major change for them and a low priority bug imo. They’ve fixed it by properly virtualising networking too. It’s mentioned on their change log but it doesn’t go into too much detail. Important point is that it’s fixed.
I figured out how to set up an encrypted partition on Ubuntu the other day. There are a bunch of ways of doing it but I found this to be the simplest. It should work on Debian too, since all the relevant packages are Debian ones anyway. In my example I’m encrypting an LVM partition (logical volume), but it should work with any device, including removable USB keys (see end notes). UPDATE: This is broken in Edgy but I figured out a simple fix, see below.
Continue reading Encrypted partitions with Ubuntu/Debian
Did you know that Firefox (and Epiphany) don’t send referrers when following a link from an SSL encrypted site? The target site cannot tell whether you clicked a link or typed the url in directly.
I don’t know about other browsers, but this seems like a sane behaviour.
When controlling access to files on a webserver developers often use the web application itself as a file server. The request comes in, the script checks for some session authentication variable or something, then streams the file from disk (hopefully from outside the webroot) to the browser.
The problem with this from a performance standpoint is that a thread/process of the web application has to be running for the entire duration of the download. With a busy webserver serving many concurrent downloads, this is an immense overhead. The web server itself should be orders of magnitude faster at serving files directly than via a web application, but you can’t just stick the files in a different directory and hope nobody finds the secret urls. The new web server on the block, Lighttpd, has some clever solutions for this problem.
Continue reading Lighttpd and Ruby on Rails: Secure and Fast Downloading
“We are extremely concerned at the ongoing culture of secrecy endemic in the planning of the identity cards proposals. The Home Ofﬁce has conducted most of its work in a covert fashion, refusing to disclose information that would inform debate, and conducting negotiations in a closed environment. This process is inimical to the creation of trust. This situation also makes further research on the proposals impossible.”
The London School of Economics has published their latest Identity Project Status Report concerning the governments Identity Cards Bill 2005.
The last report was immediately damned by the Government at every turn in what can only be described as behaviour of the intensely insecure. Why are the Government so insecure about the details of their Bill?
Continue reading Identity Project Status Report- Homeoffice misdirection
I leave for Amsterdam on Wednesday where I’m attending the Black Hat Briefings. I was at DefCon in Las Vegas a few years ago so I’m interested to see what the BHB are like in comparison. I hope it’s not just a big ugly advertis-a-thon. I’m there for a few days courtesy of work and will have photies to post when I get back I expect.
My new Laptop arrived today too (not got it in my hands though). The ickle IBM Thinkpad X40 is very portable, but I’ve been using it for more of a desktop replacement than a portable troubleshooter, hence the new Viao one. Big 17inch widescreen LCD, crazy CPUness (for Doom3 and Half Life 2 fun), and 1G RAM. I expect it’ll weigh more than two Terri Schiavos* but I’m a big guy.
* – Please note: topical reference.
I’m playing with the grsecurity patches for Linux. Unfortunately 2.6.8 changed in a way that causes major headache for the grsec team, so no planned release date for a new patch. Having some problems with strange enforcements of rlimits, potentially linked to the rlimit auditing code. I’ll hopefully get time to tinker with SELinux too.
I’ve updated my GPG key. I’ve added a new encryption key as my old one expires in Jan 2004. I also removed an old, irrelevant, signature. Update your keyrings people.
My port of that pptpd exploit to Linux was apparently so horrendous that it prompted ‘r4nc0rwh0r3’ of ‘blightninjas’ to take the time to do it properly. In my defence, the original code really sucked, and I myself only needed the testing part to work (which seemed to work for me). It also compiled fine for me with gcc 3.2.3 (worksforme(tm)). And I in no way proclaim myself to be a good C programmer! Anyway, my laziness and lameness was thoroughly ridiculed by them here. Find their own fixed version here. At least I got my name on Bugtraq. Roll on fame and the big dollar.