Hacker News Daily
I've been a member of the Hacker News website (formerly "Startup News") for slightly over 3 years, and it has grown significantly over that time. Three years ago, I could read every article which was posted, and still have time plenty of time to work on Tarsnap. It's no longer possible to read everything; even reading a small fraction of the articles can take a significant amount of time away from other activities -- a fact which even the site's creator has said he "worries about a lot".At the same time, there are a lot of very interesting articles on Hacker News. Several times recently I've read a fascinating article elsewhere and submitted it to Hacker News, only to find that it had already been on Hacker News several days earlier but had been crowded out by other articles before I noticed it. This suggests that there are probably also interesting articles which I don't discover in other ways.
To solve these twin problems -- of spending too much time reading Hacker News, and of interesting articles not surviving on the front page of the site for long enough for me to notice them -- I've created a new site: Hacker News Daily. Each day, this site will have the 10 highest-voted links which appeared on Hacker News the previous day and haven't already appeared on Hacker News Daily.
The code behind this is startlingly simple: It took me about half an hour and 100 lines of code to scrape http://news.ycombinator.com/ every 5 minutes, update a list of the day's top links, and then generate a digest at the end of the day; these digests are then fed into the 250 line "blogsh" script which I wrote back in 2005 for these Daemonic Dispatches in order to build the Hacker News Daily site.
I hope Hacker News Daily proves useful; depending on the amount of traffic it gets, I might get a separate domain for it rather than hosting it as part of daemonology.net. But even if nobody else reads it, it will still serve one important purpose: Allowing me to get work done on Tarsnap without the constant nagging worry that I might be missing a fascinating article.
Keep your eyes open
In October, I saw the following lines in the HTTP logs for the Tarsnap website (the private network IP address is due to my use of jailed stunnel for terminating the SSL connection):www.tarsnap.com 192.168.0.44 - - [27/Oct/2009:22:02:14 +0000] "POST /confirm.cgi HTTP/1.1" 303 - "https://www.tarsnap.com/confirm.cgi?address=XXXXXX&cookie=XXXXXX" "Mozilla/5.0 (Macintosh; U; Intel Mac OS X 10_6_1; en-us) AppleWebKit/531.9 (KHTML, like Gecko) Version/4.0.3 Safari/531.9"I sent an email to Apple, and earlier this week they released large number of security updates for Safari, including the following:
www.tarsnap.com 192.168.0.44 - - [27/Oct/2009:22:02:16 +0000] "GET /confirmed.html HTTP/1.1" 200 2009 "https://www.tarsnap.com/confirm.cgi?address=XXXXXX&cookie=XXXXXX" "Mozilla/5.0 (Macintosh; U; Intel Mac OS X 10_6_1; en-us) AppleWebKit/531.9 (KHTML, like Gecko) Version/4.0.3 Safari/531.9"
WebKit
CVE-ID: CVE-2010-1406
Available for: Mac OS X v10.4.11, Mac OS X Server v10.4.11, Mac OS X v10.5.8, Mac OS X Server v10.5.8, Mac OS X v10.6.2 or later, Mac OS X Server v10.6.2 or later, Windows 7, Vista, XP SP2 or later
Impact: Visiting an HTTPS site which redirects to an HTTP site may lead to an information disclosure
Description: When WebKit is redirected from an HTTPS site to an HTTP site, the Referer header is passed to the HTTP site. This can lead to the disclosure of sensitive information contained in the URL of the HTTPS site. This issue is addressed by not passing the Referer header when an HTTPS site redirects to an HTTP site. Credit to Colin Percival of Tarsnap for reporting this issue.
This is a very minor security issue: The HTTP standard states that when accessing a page via HTTP, the Referer header should be cleared rather than including an HTTPS link. WebKit generally gets this right; but prior to this fix, it would improperly include the Referer header when being redirected from an HTTPS URL to an HTTP URL (e.g., via an HTTP 303 'See Other' response).
No matter how insignificant the vulnerability is, however, it serves to illustrate an important point from my blog post last September about the inherent insecurity attached to code complexity: Eschew obfuscation! I noticed this vulnerability because I had my eyes open and the evidence of the bug was right in front of me; if that evidence had been in any way obfuscated, I might as well have had my eyes closed. Now, I suspect that very few people deliberately obfuscate their log files; but the principle applies elsewhere: Whether you're looking at source code, data files on disk, or bits being sent over a network, the easier material is to read and understand, the more likely it is that you'll notice and be able to fix vulnerabilities before your product ships -- and that you'll notice the vulnerabilities not just while specifically looking for them, but also while working on something completely different and saying to yourself "gee, that looks odd".
Isaac Asimov is often claimed to have remarked that the most exciting phrase to hear in science is not "Eureka!" but rather "That's funny..."; the same is true of computer security. Keep your eyes open and avoid obscuring your vision with obfuscation, and you're far more likely to find yourself saying those same words.
Looking for wannabe FreeBSD/EC2 users
I want to use FreeBSD in Amazon EC2. Based on feedback I've had in the past, I know I'm not alone. Unfortunately there is some work which needs to be done in FreeBSD to make it work on EC2.If you want to use FreeBSD on EC2, please send me an email with as much as possible of the following information:
- How many instances, of which types, would you expect to use?
- If you had to pick one or the other, would you prefer i386 support (32-bit -- EC2 small and medium instances) or amd64 support (64-bit -- EC2 large, XL, 2XL, and 4XL instances)?
- What purpose would you be using EC2 for (e.g., web servers, video encoding, high performance computing, et cetera)?
- What applications would you be running? (This is relevant for testing purposes.)
- Can you provide any funding for development? (If yes, how much can you contribute?)
To clarify that last point: The availability of development funding is useful both as a measure of community interest and for convincing FreeBSD developers to work on this -- I'm not personally looking for money from this, but I'm not able to do all the work required for this.
I Vespri Siciliani
... and now for something completely different. Over the past weekend I played two concerts in the first violin section of Vancouver's West Coast Symphony Orchestra: Verdi's Overture to I Vespri Siciliani, an aria from Handel's Messiah, and the Verdi Requiem. All wonderful music; but the first violin score for the Overture was horrid. Not only was it a handwritten Kalmus part from 1965; but it also had wind cues written in. Presumably the purpose was to allow the violin score to be used by a conductor; but the net result was to render it almost entirely illegible.So I fixed it. Thanks to LilyPond and about six hours of work, I now have a beautifully typeset Violin I score to Verdi's Overture to I Vespri Siciliani, which I am hereby placing in the public domain in the hope that it will be useful to some other violinist at some point (note that since Verdi died in 1901, his works are in the public domain; but individual editions may not be). The LilyPond 2.13.9 source code is also available.
Open Source: It's not just for software!
ZumoDrive rolls a hard six
I haven't had much time for blogging recently, but sometimes things come up which just beg for a response; case in point: A recent post to the ZumoDrive blog entitled "Sometimes you have to roll a hard six" about the security of the ZumoDrive cloud storage / backup service. I have to give credit to ZumoDrive for one thing: Unlike most online backup services, they published the reasons why they think their service is secure. Sadly, the credit goes no further.[EDIT 2010-03-11 18:00 I mention this below, but to place my conflict up front: I'm the author of the Tarsnap secure online backup service, which is in some ways a competitor to ZumoDrive.]
To quote from the blog post,
The file being uploaded is transferred to the ZumoDrive server which is hosted by Amazon's EC2 (Elastic Compute Cloud). It is done via 256-bit SSL encryption.Here's their first mistake: Trusting their security to SSL. There is one, and only one, good reason to use SSL for anything: It takes care of key management for you. When you're only talking to yourself -- or, as in this case, if you wrote both the client and the server code -- you can pre-distribute keys, and all of the complexities of SSL certificate handling (plus the question of whether or not you should trust the Chinese government) go away.
Next up we have this bit:
The EC2 is the workhorse. It's the liaison between the client on your computer and the ZumoDrive datacenter (which is hosted by Amazon S3; more on this below). It also services the ZumoDrive website.Even leaving aside the questionable subject "The EC2" -- I assume they meant "The ZumoDrive server hosted on EC2" -- this also raised my eyebrows. One of the keys to security is to keep separate things, well, separate -- that way, you reduce the potential for a vulnerability in one area to affect others. This is why qmail has five daemons (qmail-send, qmail-lspawn, qmail-rspawn, qmail-clean, qmail-smtpd) where other mail transfer agents have only one. Why should the security of your backups depend on whether someone can find a vulnerability in a web server?
A few lines further down, we have this classic goof:
[The ZumoDrive server, running on EC2] encrypts your actual file via 256-bit AES encryption and stores it on S3 (Simple Storage Service). AES is military grade encryption.As Bruce Schneier wrote in his famous list of signs of cryptographic snake oil, "Some companies claim 'military-grade' security. This is a meaningless term. There's no such standard." Many things have changed in the past decade, but this is not one of them: There is still no such thing as "military grade encryption". There are US standards covering the use of encryption to protect CONFIDENTIAL, SECRET, and TOP SECRET information; but merely using 256-bit AES is nowhere near enough: The entire encryption system needs to be approved (including block cipher modes, key management, vulnerability to side channel attacks, et cetera), not merely the choice of block encryption algorithm.
As it happens, there's an even worse problem: ZumoDrive is trying to keep your data safe on S3 by encrypting it on EC2. Stop and think for a moment: Who does this actually protect you from? The people who have out-of-band access to data on S3 -- Amazon employees, law enforcement, and the courts -- all have access to data on EC2; so if they want your data, all this does is force them to fish the decryption key out of ZumoDrive's EC2 instance.
ZumoDrive's security has another major flaw, too: ZumoDrive themselves. Data is uploaded not-very-securely to their not-very-secure server, which then encrypts it completely-and-utterly-brokenly (but with bogus buzzwords) prior to storing it on S3... during that process, the data is on the ZumoDrive server completely unencrypted. Anyone with access to that server -- which I'm guessing is most or all of the people who work at ZumoDrive, plus anyone who can steal their credentials (or install a trojan which steals their credentials) -- can access ZumoDrive data. Thanks to their automatic indexing of file metadata, they would even know where to find my_world_domination_plans.doc.
Finally, while I have to give ZumoDrive credit for admitting their faults (albeit unknowingly) on their blog, it's really not enough to see what they claim ZumoDrive does. As a FreeBSD developer (and Security Officer), I have to speak in favour of open source software -- not from the perspective of licensing, but simply because without seeing the source code (or doing a huge amount of work to disassemble and reverse-engineer a binary) there's no way to confirm that ZumoDrive correctly translated design into code.
The title of ZumoDrive's blog post -- sometimes you have to roll a hard six -- is a quote from Battlestar Galactica, but refers to the game of Craps where a "hard six" involves rolling a 3 on each of a pair of six-sided dice. In that vein, and taking a bit of poetic license, I'd say that ZumoDrive has rolled three security mistakes
- Relying on SSL for security when keys could be distributed out-of-band.
- Hosting their service on the same systems as their website.
- Encrypting data in EC2 and expecting that to protect it on S3.
- Calling 256-bit AES "military grade encryption".
- Having unencrypted access to user data.
- Not providing source code.
But who am I to speak? I'm just the author of a competing service -- Tarsnap. An online backup service which does not rely on SSL for its security; has its website hosted entirely separately from the backup service; encrypts data using keys held only by the user before uploading it; doesn't allow me to look at user data (because I don't have the necessary decryption keys); and provides source code for the client utility, so that you can see exactly what it is doing. In short, a backup service which does security right.