ecryptfs stores ram contents in plaintext in the container as padding

[Florian Streibelt]

Environment:
Linux flst61nb 2.6.28-gentoo-r2 #4 SMP Tue Mar 17 12:38:43 CET 2009 x86_64 Intel(R) Core(TM)2 Duo CPU T8300 @ 2.40GHz GenuineIntel GNU/Linux

When looking at the contents of the encrypted files I see random content of my System RAM.
Including the content of ~/.ssh/known_hosts, firefox Cache (html page headers) etc.

It seems ecryptfs fails in padding the files, it even seems that the padding is done after encryption.

To reproduce:
# mkdir ecryptfs_base
# sudo mount -t ecryptfs ecryptfs_base ecryptfs_base
# cd ecryptfs_base/
# for ((i=0;i<10000;i++)); do dd if=/dev/zero of=$(date +"%s-$i") bs=1 count=1 >/dev/null 2>&1; done
# cd ..
# sudo umount ecryptfs_base/
# strings ecryptfs_base/*

Most of the files contain the String _CONSOLE, some contain just filenames, some the contents of random files.

An attacker with access to the underlying filesystem thus can find random data of the system using ecryptfs lying around in plain inside the files.

I also found the contents of /etc/mtab in some of the files...

/tmp/ecryptfs_base /tmp/ecryptfs_base ecryptfs rw,ecryptfs_sig=90fe7cccfdb1a0ba,ecryptfs_cipher=aes,ecryptfs_key_bytes=16 0 0

so one can find out which key was used to mount the fs

In addition I think there could also be private data of privileged processes run by root in some of the files, so an attacker could use ecryptfs to read (kernel?) memory and might find a password or similar.

[Tyler Hicks (tyhicks)]

I just took another look at the patch a realized I wasn't freeing the multiple pages allocated with ecryptfs_get_zeroed_pages(). I also realized that neither of the ecryptfs_write_metadata_to_*() functions were using the crypt_stat, so I removed those function params.

I'm attaching an updated patch that also has a slightly more descriptive commit message.

[Tyler Hicks (tyhicks)]

Please ignore the comment I made with the last patch attachment. I had attached a patch, then attached an updated version. I've now deleted the original patch.

Still learning the ways of launchpad :)

[Tyler Hicks (tyhicks)]

This should be the final revision

[Dustin Kirkland  (kirkland)]

Okay, on the userspace side, we need to provide a way to "fix" affected files, where kernel data has been leaked into the encrypted file headers, once the user is running a fixed kernel.

I have created a small shell script, ecryptfs-rewrite-file, which will do this, and a manpage with instructions.

You can view the latest source of this shell script in the source control at:
 * http://bazaar.launchpad.net/~ecryptfs/ecryptfs/ecryptfs-utils/annotate/head%3A/src/utils//ecryptfs-rewrite-file

And this manpage explains how the script is intended to run:
 * http://bazaar.launchpad.net/~ecryptfs/ecryptfs/ecryptfs-utils/annotate/head%3A/doc/manpage//ecryptfs-rewrite-file.1

Basically:
 $ cd $YOUR_MOUNT_POINT
 $ find . -xdev -print0 | xargs -r -0 /usr/bin/ecryptfs-rewrite-file
 $ ecryptfs-umount-private
 $ sync

This will mostly affect Ubuntu Jaunty Alpha/Beta users. I will coordinate with the Ubuntu Security Team for the best mechanism for communicating these instructions.

This script will be in the ecryptfs-utils-73 release for merging by other distros too.

:-Dustin

[Dustin Kirkland  (kirkland)]

Upstream commit:
 * http://git.kernel.org/?p=linux/kernel/git/torvalds/linux-2.6.git;a=commit;h=8faece5f906725c10e7a1f6caf84452abadbdc7b

:-Dustin

[Tim Gardner (timg-tpi)]

http://kernel.ubuntu.com/git?p=ubuntu/ubuntu-jaunty.git;a=commit;h=2948c4e71c47eae1de4a259eba1e2af778cbd052

[Launchpad Janitor (janitor)]

This bug was fixed in the package linux - 2.6.28-11.37

---------------
linux (2.6.28-11.37) jaunty; urgency=low

  [ Alex Deucher ]

  * SAUCE: radeon: add some new pci ids
    - LP: #334101

  [ Amit Kucheria ]

  * Updating configs - rip out orion5x and mv78xx0 flavours

  [ Andy Whitcroft ]

  * SAUCE: tone down the synaptics warning to avoid triggering kerneloops
    - LP: #330606

  [ Upstream Kernel Changes ]

  * ext4: fix header check in ext4_ext_search_right() for deep extent
    trees.
    - LP: #346194
  * eCryptfs: NULL crypt_stat dereference during lookup
    - LP: #345766
  * eCryptfs: Allocate a variable number of pages for file headers
    (CVE-2009-0787)
    - LP: #345544

 -- Tim Gardner <email address hidden> Mon, 23 Mar 2009 09:24:32 -0600

[Launchpad Janitor (janitor)]

This bug was fixed in the package ecryptfs-utils - 73-0ubuntu1

---------------
ecryptfs-utils (73-0ubuntu1) jaunty; urgency=low

  [ Dustin Kirkland ]
  Userspace fixes for LP: #345544, CVE-2009-0787
  * src/utils/ecryptfs-rewrite-file: new script, to rewrite a file,
    forcing it to be re-encrypted when written to disk
  * doc/manpage/ecryptfs-rewrite-file.1: documentation added

  Unrelated fixes in this release
  * src/utils/ecryptfs-mount-private, src/utils/ecryptfs-setup-private,
    src/utils/ecryptfs-setup-swap: use head/line for prompting and reading
    input

  [ Michal Hlavinka ]
  * ecryptfs-setup-private: don't fail with syntax error when kernel
    module not loaded
  * *.desktop: make desktop files standards compliant
  * umount.ecryptfs: don't sigsegv when arguments are missing

 -- Dustin Kirkland <email address hidden> Fri, 20 Mar 2009 17:26:13 -0500

[Tyler Hicks (tyhicks)]

Fix released in 2.6.29 and 2.6.28.9

[Tyler Hicks (tyhicks)]

For completeness, I should mention that "_CONSOLE" will be found in the headers of the eCryptfs file. eCryptfs models its header data around RFC 2440 (http://www.ietf.org/rfc/rfc2440.txt). To read more about the meaning of "_CONSOLE", see section 5.9.