ecryptfs team mailing list archive

[Dustin Kirkland <dustin.kirkland@xxxxxxxxx>]

** Changed in: ecryptfs
       Status: Triaged => Fix Committed

** Changed in: ecryptfs-utils (Ubuntu)
       Status: Triaged => Fix Committed

-- 
You received this bug notification because you are a member of eCryptfs,
which is subscribed to the bug report.
https://bugs.launchpad.net/bugs/883238

Title:
  encrypted-private mount passphrases can be leaked to disk

Status in eCryptfs - Enterprise Cryptographic Filesystem for Linux:
  Fix Committed
Status in “ecryptfs-utils” package in Ubuntu:
  Fix Committed

Bug description:
  When a root user *migrates* an existing user's home directory to an
  encrypted home, instructions are provided which say to login to the
  new account before rebooting. This is so the newly generated mount
  passphrase can be wrapped with the user's login passphrase before it
  is written to disk. During the time between account creation and the
  initial login, the unencrypted mount passphrase is stored in a tmpfs
  mount (/dev/shm/) and the file is protected by restrictive DAC
  permissions.

  If the instructions are not followed and the system is shut down
  before the new user logs in, the ecryptfs-utils-save init script conf
  file (/etc/init/ecryptfs-utils-save.conf) moves the unencrypted mount
  passphrase from the tmpfs mount to a folder in /var/tmp/ to persist
  across the reboot. Upon the next boot, the unencrypted mount
  passphrase is moved back to the tmpfs mount in anticipation of the new
  user performing the initial login.

  The security concern is that the unencrypted mount passphrase is
  leaked to disk, compromising the user's encrypted files in the case of
  an offline attack. Because Linux does not have a secure file deletion
  mechanism, an attacker may be successful in examining the disk and
  extracting the mount passphrase which can then be used to unwrap each
  file encryption key. The file encryption keys can then be used to
  unencrypt the file contents.

  The only situation where this happens is when a root user migrates an
  existing user's home, and that user does *not* follow the directions
  as printed to screen.  Furthermore, it's worth noting that in such
  migration scenarios, ALL of that user's home directory is already
  written to disk in clear text prior to the migration.  Users migrating
  their home directories are warned as much as possible of the risk of
  extracting such contents from disk.

To manage notifications about this bug go to:
https://bugs.launchpad.net/ecryptfs/+bug/883238/+subscriptions