Swap files can contain evidence of browsing history

[arthuredelstein]

Two forensic reports describe extracting Tor Browser browsing history from a Windows pagefile.sys and hiberfil.sys:

See
​http://computerforensicsblog.champlain.edu/wp-content/uploads/2014/06/One-User-Multiple-Devices-Cross-Platform-Recovery-and-Analysis...-Saliba-Landry-5-20-2014.pdf#33
and
​https://web.archive.org/web/20160403075329/http://dfrws.org/2015eu/proceedings/DFRWS-EU-2015-short-presentation-1.pdf#16

Is there any way we can programmatically clean up the pagefile on New Identity and/or browser exit? What about OS X and Linux?

[yawning]

As far as Linux goes, not without patching the kernel. The situation is likely the same on other operating systems.

On the U*IXes, you could mlockall() on process startup assuming that the system is configured to allow pinning sufficient memory (ulimit -l), but given how big the runtime footprint of Firefox is, that's probably a really bad idea. If there's a extremely limited amount of sensitive information, then allocating the backing store from a mlock()ed region may be sufficient, but I suspect patching Firefox to do so would be a fairly large undertaking.

The answer here IMO is: Either use encrypted swap (Vista and later support this on Windows, dunno about Darwin), use full disk encryption, or use Tails.

[cypherpunks]

Replying to yawning:
Linux, FreeBSD, and OpenBSD all support encrypted swap. OpenBSD was the first to support it since ~2000, on by default (vm.swapencrypt.enable=1) since OpenBSD 3.8. I believe OS X also does by default.
​https://wiki.archlinux.org/index.php/Dm-crypt/Swap_encryption
​https://help.ubuntu.com/community/EnableHibernateWithEncryptedSwap
​https://www.freebsd.org/doc/handbook/swap-encrypting.html
​http://www.openbsd.org/papers/swapencrypt-slides.pdf

Another option is to avoid the use of swap and use ZRam ​https://wiki.debian.org/ZRam

[yawning]

Yeah, anything modern supports encrypted swap. Dunno what people on XP should do (one of the Truecrypt replacements maybe). Windows does not have mlockall() so you get to do things the hard way with VirtualLock() (or VirtualAlloc().

I still stand by "this should be up to the user to solve, perhaps with a list of recommendations for various platforms in the documentation somewhere that no one will ever read".

[sharifolorin]

Replying to yawning:

On the U*IXes, you could mlockall() on process startup assuming that the system is configured to allow pinning sufficient memory (ulimit -l), but given how big the runtime footprint of Firefox is, that's probably a really bad idea.

Is there a reason this would be any worse than just running without a swap partition (as Tails does)?

The answer here IMO is: Either use encrypted swap (Vista and later support this on Windows, dunno about Darwin), use full disk encryption, or use Tails.

Yep, though FDE on its own (e.g., encrypted LVM physical volume with a root LV and a swap LV, as I believe Debian still does if you ask it to autoconfigure luks+lvm) isn't enough for some relevant threat models (those in which the user can be forced physically or legally to provide the FDE key). Generating a fresh swap key in-memory on each boot would work; I believe OpenBSD does this by default, but I'm not sure about most Linux distributions/Windows/OS X.

[yawning]

Is there a reason this would be any worse than just running without a swap partition (as Tails does)?

Doing so requires increasing the locked page limit for the user (/etc/security/limits.conf), which in turn requires elevated (root) privileges among other things. Unilaterally disabling paging for a gigantic process is sort of a crappy thing to do when there are people with correct setups as well...

I'm not sure about most Linux distributions/Windows/OS X.

I'd hope that Linux distributions opt for that behavior, since it's easy and the right thing to do. I *think* Windows randomizes the key. Don't know about Darwin.

[bugzilla]

hiberfil.sys is not your problem, but it is good to warn users that opened TBB is copied to disk with all sensitive data (current session) when they hibernate (but they must know it from OS manual).

Is there any way we can programmatically clean up the pagefile on New Identity and/or browser exit? What about OS X and Linux?

Direct disk access instead of OS ;)

Now seriously:
You MUST clean up memory after usage like memwipe in Tor does!

[boklm]

It looks like Windows has a ClearPageFileAtShutdown option to clear the paging file at shutdown:
​https://support.microsoft.com/en-us/kb/314834

[mikeperry]

Replying to boklm:

It looks like Windows has a ClearPageFileAtShutdown option to clear the paging file at shutdown:
​https://support.microsoft.com/en-us/kb/314834

Can we set this key from Tor Browser as a non-admin user? Also, I don't know if "Machine Shutdown" is the right time to clear this data.

For another approach: I discussed this with some folks at OTF, and they suggested a "Secure Shutdown" option that attempts to allocate and zero all of the memory on the system in a malloc+memset loop, until malloc fails (presumably once all the swap space has been used). We'd want probably to do this from a separate process launched after Tor Browser actually exits, or at least after we're certain that the current Tor Browser heap is fully freed. We'd want to prompt the user from Tor Browser before doing this, since it will be slow and other apps may OOM, but otherwise this approach seems simple and cross-platform. It might do the trick?

[yawning]

Replying to mikeperry:

For another approach: I discussed this with some folks at OTF, and they suggested a "Secure Shutdown" option that attempts to allocate and zero all of the memory on the system in a malloc+memset loop, until malloc fails (presumably once all the swap space has been used). We'd want probably to do this from a separate process launched after Tor Browser actually exits, or at least after we're certain that the current Tor Browser heap is fully freed. We'd want to prompt the user from Tor Browser before doing this, since it will be slow and other apps may OOM, but otherwise this approach seems simple and cross-platform. It might do the trick?

That won't work on the majority of Linux installs, due to memory over-commit (malloc never fails, and the OOM killer will kick in when the system freaks out trying to service page faults as you memset), and is totally pointless on OSX (as of 10.7, unless the user disabled swap encryption).

I still stand by this being a user education problem. The only OSes that don't have support for having the OS handle swap encryption are EOLed.

[arthuredelstein]

Replying to yawning:

I still stand by this being a user education problem. The only OSes that don't have support for having the OS handle swap encryption are EOLed.

So maybe Tor Browser could include a check to see if swap encryption is enabled, and if not, show a warning to the user and either offer to turn it on (if possible) or display instructions on how to turn it on for the given OS.