ecryptfs stores ram contents in plaintext in the container as padding

Bug #345544 reported by Florian Streibelt on 2009-03-19
Affects Status Importance Assigned to Milestone
Tyler Hicks
ecryptfs-utils (Ubuntu)
linux (Ubuntu)
Tim Gardner
Tim Gardner

Bug Description

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.

Changed in ecryptfs:
assignee: nobody → tyhicks
importance: Undecided → Critical
Changed in ecryptfs:
status: New → Confirmed
Changed in ecryptfs-utils (Ubuntu):
importance: Undecided → Critical
status: New → Confirmed
Tyler Hicks (tyhicks) on 2009-03-20
Changed in ecryptfs:
status: Confirmed → In Progress
Tyler Hicks (tyhicks) wrote :

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) wrote :

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) wrote :

This should be the final revision

Dustin Kirkland  (kirkland) wrote :

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:

And this manpage explains how the script is intended to run:

 $ 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.


Changed in ecryptfs-utils (Ubuntu):
status: Confirmed → In Progress
Changed in linux (Ubuntu):
assignee: nobody → timg-tpi
importance: Undecided → Critical
milestone: none → ubuntu-9.04
status: New → In Progress
Tim Gardner (timg-tpi) wrote :
Changed in linux (Ubuntu Jaunty):
status: In Progress → Fix Committed
Launchpad Janitor (janitor) wrote :

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
    - LP: #346194
  * eCryptfs: NULL crypt_stat dereference during lookup
    - LP: #345766
  * eCryptfs: Allocate a variable number of pages for file headers
    - LP: #345544

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

Changed in linux:
status: Fix Committed → Fix Released
Launchpad Janitor (janitor) wrote :

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

  [ 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

Changed in ecryptfs-utils:
status: In Progress → Fix Released
Tyler Hicks (tyhicks) on 2009-03-23
Changed in ecryptfs:
status: In Progress → Fix Committed
Tyler Hicks (tyhicks) wrote :

Fix released in 2.6.29 and

Changed in ecryptfs:
status: Fix Committed → Fix Released
Tyler Hicks (tyhicks) wrote :

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 ( To read more about the meaning of "_CONSOLE", see section 5.9.

To post a comment you must log in.
This report contains Public Security information  Edit
Everyone can see this security related information.

Other bug subscribers