What to do when you lose your computer
I was recently thinking about security as a result of finding the hard copy of a PGP revocation certificate I had printed, when I realized: I had no clue what I should do in case the physical security of my computer was compromised (i.e., if it was stolen or went missing for an extended period of time). So I decided to take stock of how many secrets I have here and what the best way to render them useless or remote-erase them would be in case I lost it, as well as to make it hard for anybody who steals it to get any use out of the secrets before I can make them useless.
I store my passwords in a KeePass password database, encrypted using AES using a reasonably long passphrase; I have it set to require the passphrase if the window loses focus for more than 30 seconds. I then synchronize it using Dropbox between various computers, as well as so I can download it if I’m on a new computer that I trust enough to log into stuff on. I also have my PGP private key on my laptop. Noticeably, there are several password I have that are not written down anywhere: my MIT Kerberos password, my Gmail password (most of my password reset e-mails would be sent there, so if it was compromised everything else would be too), the KeePass database password, and my Dropbox password. And of course there’s a password on my laptop, but I wouldn’t rely on that for anything beyond keeping someone from looking at my stuff while I’m temporarily out.
So what does that mean in case the laptop’s stolen? Step one is to go everywhere I know of that I can sign into using public key cryptography on this machine and delete the keys; fortunately, the only such machine at the moment is the Github remotes and my VM; I’d also force-disconnect any ssh sessions that I left open by killing the processes. After that’s done, I change my Gmail password in case I left myself logged in or cookied or something, and forcibly sign out all my other accounts using the link on the bottom. If the password’s been changed or it’s been more than a day or so since I last saw the laptop, I assume all my accounts are compromised. The third step is to backup the password database and then delete it from Dropbox; if the person who stole it isn’t smart, the next time it connects to the internet it’ll delete the local copy. Interestingly, even if I change the Dropbox password, the computer will still have access to my files; if I want to disable syncing, I have to unlink the computer it on the website (which does tell me when the last sync occurred). Then I change the password for my AOL and MSN accounts; MSN only lets you sign on from one place at a time, but AOL doesn’t, and I don’t know if it’s possible to force a logout. Finally, I’d probably revoke my public key; I know enough people who can get it signed that are in the strong set that it’s not terribly difficult to get back in there. I have a printout of my revocation certificate for just this occasion.

Security vulnerability in Haskell with CGI
Compiled Haskell programs all include special RTS (Run Time System) options, that change things like the number of cores that it runs on, various internal things relating to how often garbage collection runs, etc. They’re specified by invoking the program like ./foo +RTS -m10 -k2000 -RTS to run the GHC-compiled program ‘foo’, reserving 10% of the heap for allocation and setting each thread’s stack size to a maximum of 2000 bytes. In the current build of GHC, there is no way to disable these options from working (although the option –RTS will make all further options be interpreted as normal, non-RTS options). The problem is that the option -tout will write profiling data to the file out. So, if your program is setuid root, anybody who runs it can write the profiling data to, say /etc/passwd and render the system unusable. They don’t get to pick what gets written, so they can’t add a backdoor for themselves, but they can essentially scribble over whatever files they want. This is bug #3910, and the fix (disabling RTS by default) has been uploaded.
Now, one of the more little-known features of CGI is that if you pass a query string that does not contain any = signs to a CGI script, the httpd may pass the string along as command-line arguments. This is specified in section 4.4 of RFC 3875, and it specifies how the query string SHOULD be turned into arguments (although it does not say anything about whether the httpd should behave this way, only that some do). This is an example script that only outputs its arguments in a comma-separated list; the link gives it some sample arguments. Note that by URL-escaping, you can send arbitrary strings through… including +RTS. So if that were, say, a Haskell script, I could pass the query string ?%2BRTS+-tindex.html+-RTS and overwrite index.html.
There are three ways to get around this: first, GHC 6.12.2 has the -no-rtsopts option, which will obviously disable RTS options. So if you just recompile your script with that, it’ll be safe. Note that 6.14 will disable the RTS options by default; the 6.12.2 patch didn’t for backwards-compatibility reasons. Second, if you don’t want to use 6.12.2 for whatever reason, you can wrap it in a shell script that calls it with no options. For example, replace the Haskell script with a shell script called, say, hscript.cgi (if your Haskell program is called hscript) that calls it with no arguments, e.g.
./hscript.real
and rename the Haskell script to hscript.real, so that it doesn’t get run as CGI (I’m assuming that .real files don’t get run as CGI on your machine!) Another thing you can do is to add the following to your .htaccess, which will give 403 Forbidden errors to anybody passing RTS arguments in the URL:
RewriteCond %{QUERY_STRING} ^(?:[^=]*\+)?(?:%2[bB]|(?:-|%2[dD]){1,2})(?:%52|R)(?:%54|T)(?:%53|S)(?:\+[^=]*)?$
RewriteRule ^ - [F]
This will solve it for every Haskell script you use, but relies on the regex being correct, which isn’t something I can guarantee.
