/var/crash is unencrypted

[Julian Yon]

When using encrypted (ecryptfs) home directories, although the swap device is encrypted there is a potential information leak via /var/crash. I was able to successfully recover plaintext content from a file being edited within the encrypted directory when the editor crashed (triggered by SIGILL for testing) simply by mounting the root device on another system and extracting the core dump from the .crash file. As these files remain on the filesystem until cleaned up by cron this represents a significant vulnerability, especially for laptop users.

To reproduce:
1) Open a sensitive file for editing (e.g. in vim)
2) Trigger a core dump in the editor
[Alternatively: 1&2) steal a laptop]
3) Mount the device containing /var/crash on another system
4) Extract core dumps from /var/crash/*.crash
5) Search the dumps for sensitive plaintext

ProblemType: Bug
DistroRelease: Ubuntu 12.10
Package: apport 2.6.1-0ubuntu6
ProcVersionSignature: Ubuntu 3.5.0-18.18-lowlatency 3.5.7
Uname: Linux 3.5.0-18-lowlatency x86_64
ApportVersion: 2.6.1-0ubuntu6
Architecture: amd64
Date: Fri Nov 9 16:40:08 2012
EcryptfsInUse: Yes
InstallationDate: Installed on 2012-10-11 (28 days ago)
InstallationMedia: Ubuntu-Studio 12.04.1 "Precise Pangolin" - Release amd64 (20120818)
MarkForUpload: True
PackageArchitecture: all
SourcePackage: apport
UpgradeStatus: Upgraded to quantal on 2012-10-26 (14 days ago)

[Tyler Hicks (tyhicks)]

Hi Julian - thanks for the bug report!

As the upstream maintainer of eCryptfs, I'd like to point out that this is a well known problem with partial disk encryption technologies such as eCryptfs. Information leaks are bound to happen when applications can write to locations outside of the encrypted mount point ($HOME, in your case).

The only solution to prevent unintentional information leaks to non-encrypted locations in the filesystem is to use full disk encryption solutions, such as LUKS/dm-crypt. For some users, partial encryption is the best solution while other user may require full disk encryption so Ubuntu offers both solutions.

I'm going to make this bug public so that the apport folks can have a look and determine if there is an easy, apport-specific solution but I expect them to mark this as Won't Fix.

[Julian Yon (j6nsap)]

I haven't asked apport to write core dumps outside of $HOME. It just does is BY DEFAULT. As someone who has used GNU/Linux since the mid-90s and had countless core dumps land somewhere in my home directory I shouldn't have to suddenly worry about them ending up somewhere else. I also shouldn't have to use full-disk encryption to ensure that a small set of sensitive files are safe. Encryption isn't without cost - I don't want to have a pointless encryption layer in place while I'm recording direct to HD. This is 2012, not 1992 - “all or nothing” solutions don't cut it. If swap is encrypted, then core dumps should be too. Otherwise what's the point?

Why have you made this bug public? Why is an easy fix the goal? Why do you expect WONTFIX? Are you saying that if a fix isn't easy, it isn't worth doing? Dumping sensitive data somewhere public IS A BUG.

You can patronisingly point out as many “well known problems” as you like. It doesn't change the fact that this particular problem doesn't exist on Debian but does on Ubuntu, because they've decided to dump sensitive data in an unencrypted directory.

[Marc Deslauriers (mdeslaur)]

Using ecryptfs instead of full disk encryption is a trade-off. There are countless other directories where private information may get stored, and which isn't encrypted by default, such as /tmp, /var/tmp, etc.

You can turn off apport's core dump handling by modifying the /etc/default/apport file.

[Julian Yon (j6nsap)]

The problem with /var/crash is that it violates the principle of least surprise. Mounting /tmp and /var/tmp on tmpfs is a pretty obvious step to take for anyone who is familiar with any modern GNU/Linux flavour. As apport is Ubuntu specific it's considerably less obvious, and as this has a security implication this is a Bad Thing™. And I don't think “turn the feature off altogether” is a particularly good answer. It's on by default out of the box which means it's insecure by default.

Having thought about it, I think an obvious fix would be to dump into a per-user ~/.crash directory rather than have a global dropbox. This way they'd have the same level of protection as the user's home directory.

[Marcus Tomlinson (marcustomlinson)]

This release of Ubuntu is no longer receiving maintenance updates. If this is still an issue on a maintained version of Ubuntu please let us know.

[Launchpad Janitor (janitor)]

[Expired for apport (Ubuntu) because there has been no activity for 60 days.]