How can I keep my plaintext data from leaking?

October 17, 2005 6:34 PM

I'm writing some personal wiki software that I want to make as secure as possible. Think wiki software in the footsteps of Tinfoil Hat Linux. The software is intended to run as a CGI Perl script though Apache on the local machine, with data stored in encrypted XML files that will be decrypted for display by the Crypt::GPG module. So the question is, where could plaintext data escape to? More inside...

The most obvious is the browser (which, in my usage, would be Firefox on Debian), but I've ascertained that one can prevent Mozilla and most other browsers from caching data by using HTTPS. What about Apache itself? Does apache cache data by defualt in any way (other than access logs)? Is there something I'm not thinking of?

A bit paranoid? Maybe, but I do intend to commit every facet of my life to this thing, so a little parnoia is warranted.

posted by phrontist to computers & internet (27 comments total)

Oh, and does something like this exist already? My google-fu is fairly strong, but I may have overlooked something...
posted by phrontist at 6:35 PM on October 17, 2005

You're using plain text when you store the data in your computer's RAM. Stream the decrypted output and don't decrypt until the last second. Also, depending on Apache, which has had its share of security exploits, is a mistake. Apache also has all sorts of buffering it does, if not outright caching. To eliminate this attack vector, you might have to whip up your own web server.
posted by nixerman at 6:46 PM on October 17, 2005

nixerman: Okay, I thought that may be the case. I'm not opposed to the idea, I just wanted to know if Apache could be adapted to prevent wasting time.
posted by phrontist at 6:52 PM on October 17, 2005

Don't forget the swap file.
posted by event at 6:52 PM on October 17, 2005

I think mini httpd may fit the bill...

event: I've heard many refrences to the dangers the swap file represents... and it makes sense. But is there any way to protect against it without some sort of crazy intrusive kernel modification.
posted by phrontist at 7:01 PM on October 17, 2005

Googling about it would seem the best I can do is wiping my swap file periodically.
posted by phrontist at 7:04 PM on October 17, 2005

The temporary buffers used by Perl to decrypt the strings will almost definitely remain in memory.

It would be a lot more secure to run this as a CGI, because the perl interpreter will terminate after each request, and the operating system will reclaim all of the memory used. I believe that all modern OSes are careful to zero memory used by one terminated process before giving it to another, because otherwise you could leak all kinds of privileged information.

On top of that, you should use an encrypted swap file. That way, when the computer is reset the previous contents of the swap file are irretrievable because the kernel picks a new random key at bootup that is not saved anywhere, and hence lost at each reset. That way you don't have to worry about zeroing the swapfile or any such nonsense. This should be a stock option on all the *BSDs and linux, but you should be using OpenBSD anyway.
posted by Rhomboid at 7:17 PM on October 17, 2005

Whoops, I somehow read your original question as saying that you were using mod_perl, so obviously the part about running as CGI won't apply.
posted by Rhomboid at 7:18 PM on October 17, 2005

Oh, and another thing you might find useful is to grep /proc/kcore for known plaintext strings in a message that has already been decrypted and should not exist any more. You will obviously have to be root to do this.

Note that you can't just say "grep foobar /proc/kcore" because the commandline for the grep process itself contains the string "foobar" and it will match. So you will have to use a RE that does not match itself - or some creative quoting.
posted by Rhomboid at 7:22 PM on October 17, 2005

Yeah, like Rhomboid says, you should be using OpenBSD: use sysctl to set vm.swapencrypt.enable and then reboot.

Also, who is your adversary? Other vaild users? Somebody other than you with root? Somebody with physical access to the machine?
posted by event at 7:31 PM on October 17, 2005

event: ideally the data would be non-recoverable to someone with physical access to the harddrive
posted by phrontist at 7:50 PM on October 17, 2005

(I am already familiar with a number of clever ways to foil keylogging and such)
posted by phrontist at 7:53 PM on October 17, 2005

But you're not, for example, worried about some other user with root?

If you're only concerned about somebody coming into your home and taking your hard disk, consider instead storing your data and possibly even your applications and their caches, etc., on an encrypted partition. This will give you nearly the same results, but with all off-the-shelf software. (Of course, you still must use an encrypted swap.)

A key tenet in writing secure software is that the more eyeballs that look at a the program, the more likely it is that any bugs or flaws in it will be caught and fixed. Anything you homebrew will only have been analyzed by one set of eyeballs.
posted by event at 8:09 PM on October 17, 2005

event: This will, when it reaches some degree of usability, be put on sourceforge or something similar. I did not mean to imply that I was not concerned about other users with root, it simply seemed to me that physical access to the harddrive is "worse" and therefore would include such a scenario...

is this an incorrect presumption? Is there something root can do that someone with physical harddrive access can not? If so, include that as a "fear".
posted by phrontist at 8:25 PM on October 17, 2005

If your adversary has root and is logged on at the same time you're running your application, you can no longer trust your machine. The bad guy can dump live snapshots of RAM or snatch copies of your keys.

If the machine is in your possession, then somebody has to either get root from you, or use an exploit to break in. OpenBSD is your best protection on this front. If the machine is remote, whoever possesses the machine effectively also has root. A trustworthy remote admin is your best (and only) protection here.
posted by event at 9:04 PM on October 17, 2005

I don't get what you're trying to do, exactly.

If you use Apache, I can hook into the request chain at any number of points and retrieve your decrypted content (for example, the output filter would be my first choice). And if I have root... well, then all bets are off. I could replace the httpd you're using, or perhaps alter the openssl lib so that it saves a dump of anything running through it. Or maybe I grab your SSL key and use it to decrypt raw data dumps. The possibilities are endless.

There are all sorts of problems on the remote end also. Various browser implementations ignore caching rules whenever they please. And some users (notably corporate or people whose ISP gives them "acceleration" software) will run behind proxies that will cache the data anyways (yes, even for SSL connections). The new engine in Firefox has also started storing previously visited pages in memory (up to 7 I think, to make navigation snappier and comply with DOM rules) so you have plenty of swap issues there.

What I don't understand is how you plan on storing the GPG private key. A) if it's on the drive, unencrypted then I can just snatch it and decrypt all your content. B) if it's encrypted, then you're talking about SSHing in and entering a password each time your server dies (never achieve any 9's that way). C) if it's remote then you have the same problem as (B).

I'm not sure the level of security you desire is achievable.
posted by sbutler at 10:39 PM on October 17, 2005

Actually, I take back what I said about proxies. For SSL they should use CONNECT.
posted by sbutler at 10:41 PM on October 17, 2005

They can do a MITM-style proxy of SSL, but it will require that they replace the cert presented by the remote with one of their own, which obviously won't be trusted unless the end user has installed the ISPs key in their chain of trust. So, that's easy enough to deal with as you can just manually verify the fingerprint of the cert if it is ever doubted. (Or, if you're doing self-signed certs, pre-install your CA cert into your browser before hand.)
posted by Rhomboid at 1:04 AM on October 18, 2005

The most secure to prevent someone with physical access from recovering the data would be to run VMWare/QEMU/User-mode-linux/etc. from an encrypted partition. That takes care of everything (swap/temporary files/deleted files/etc.)
posted by Sharcho at 4:06 AM on October 18, 2005

so this is purely for personal access? why not leave it encrypted throughout the server process and decrypt in the browser? you could do that fairly easily with javascript, assuming there's a js crypto library out there.
posted by andrew cooke at 5:53 AM on October 18, 2005

I'm sorry, I misunderstood event when he/she asked for clarification. The assumption is that the adversary does not have root access to the machine while the wiki is being accessed. The assumption is that they have full access after the fact.

This will be written to run locally only. Nothing is going to be passing over a network, trusted or otherwise. The webserver is simply a way to use a web browser's existing text formatting/rendering capabilities.
posted by phrontist at 6:23 AM on October 18, 2005

andrewcooke: That is quite clever... not for this particular application, but it certainly has potential.
posted by phrontist at 6:25 AM on October 18, 2005

Sarcho: Could you describe how exactly that would work? I'm guessing you mean running a User Mode Linux process that mounts an encrypted file system and running wiki software within it. But wouldn't the UML process, because it is running inside the the "real" operating system, still be vulnerable to having memory leak into the swap file? Wouldn't one still need to have the main linux OS using an encrypted swap file?
posted by phrontist at 6:42 AM on October 18, 2005

Sarcho: Or to pose the question differently, what security benefit does using User Mode Linux achieve that wouldn't be achieved by using an encrypted file systems for wiki data and swap?
posted by phrontist at 6:44 AM on October 18, 2005

It means that instead of having to worry about protecting the browser, every application, file systems, temporary files, etc. you only have to worry about making sure that one file (which contains the image of the virtual machine) will be encrypted. Inside the virtual machine you can completely disable networking, and make all browsing from inside the virtual machine, without limiting the host system.

Another approach would be a LiveCD and everything would be stored on an encrypted USB key.
posted by Sharcho at 5:17 PM on October 18, 2005

BTW: With memory prices today, you'd might want to buy a bit more RAM, completely disable swapping and point /tmp to a ramdisk, so you'll have less security issues to worry about.
posted by Sharcho at 5:42 PM on October 18, 2005

On the topic of using the browser to do the decryption, here is an example of an implementation.
posted by Rhomboid at 9:10 PM on October 18, 2005