ecryptfs team mailing list archive

[Dustin Kirkland <dustin.kirkland@xxxxxxxxx>]

Attaching a patch that fixes these problems.  I personally don't think
that this is CVE-worthy, but I'll keep the patch private until you guys
say so :-)  Cheers!

** Description changed:

- When an encrypted home or private directory is set up, 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.
+ 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.

** Patch added: "882314.ecryptfs.patch"
   https://bugs.launchpad.net/ecryptfs/+bug/883238/+attachment/2577190/+files/882314.ecryptfs.patch

-- 
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:
  Triaged
Status in “ecryptfs-utils” package in Ubuntu:
  Triaged

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