ecryptfs team mailing list archive

[Launchpad Bug Tracker <883238@xxxxxxxxxxxxxxxxxx>]

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

---------------
ecryptfs-utils (94-0ubuntu1) precise; urgency=low

  [ Dustin Kirkland ]
  * scripts/release.sh:
    - fix release script
    - bump ubuntu release
  * doc/manpage/ecryptfs-recover-private.1, src/utils/ecryptfs-migrate-
    home (properties changed: -x to +x), src/utils/ecryptfs-recover-
    private:
    - add a --rw option for ecryptfs-recover-private
  * src/utils/ecryptfs-migrate-home: LP: #820416
    - show progress on rsync
  * debian/ecryptfs-utils.ecryptfs-utils-restore.upstart,
    debian/ecryptfs-utils.ecryptfs-utils-save.upstart,
    src/utils/ecryptfs-migrate-home,
    src/utils/ecryptfs-setup-private: LP: #883238
    - remove 2 upstart scripts, which attempted to "save" users who didn't
      login after migrating their home; instead, we now require the root
      user to enter user passwords at migration time
  * debian/copyright, debian/ecryptfs-utils.ecryptfs-utils-
    restore.upstart, debian/ecryptfs-utils.ecryptfs-utils-save.upstart,
    doc/manpage/ecryptfs.7, doc/manpage/ecryptfs-add-passphrase.1,
    doc/manpage/ecryptfs-generate-tpm-key.1, doc/manpage/ecryptfs-
    insert-wrapped-passphrase-into-keyring.1, doc/manpage/ecryptfs-
    mount-private.1, doc/manpage/ecryptfs-recover-private.1,
    doc/manpage/ecryptfs-rewrap-passphrase.1, doc/manpage/ecryptfs-
    rewrite-file.1, doc/manpage/ecryptfs-setup-private.1,
    doc/manpage/ecryptfs-setup-swap.1, doc/manpage/ecryptfs-stat.1,
    doc/manpage/ecryptfs-umount-private.1, doc/manpage/ecryptfs-unwrap-
    passphrase.1, doc/manpage/ecryptfs-wrap-passphrase.1,
    doc/manpage/fr/ecryptfs-add-passphrase.1, doc/manpage/fr/ecryptfs-
    generate-tpm-key.1, doc/manpage/fr/ecryptfs-insert-wrapped-
    passphrase-into-keyring.1, doc/manpage/fr/ecryptfs-mount-private.1,
    doc/manpage/fr/ecryptfs-rewrap-passphrase.1,
    doc/manpage/fr/ecryptfs-setup-private.1, doc/manpage/fr/ecryptfs-
    umount-private.1, doc/manpage/fr/ecryptfs-unwrap-passphrase.1,
    doc/manpage/fr/ecryptfs-wrap-passphrase.1, doc/manpage/fr/ecryptfs-
    zombie-kill.1, doc/manpage/fr/ecryptfs-zombie-list.1,
    doc/manpage/mount.ecryptfs_private.1, doc/manpage/pam_ecryptfs.8,
    doc/manpage/umount.ecryptfs.8,
    doc/manpage/umount.ecryptfs_private.1,
    src/pam_ecryptfs/pam_ecryptfs.c,
    src/utils/ecryptfs_add_passphrase.c,
    src/utils/ecryptfs_insert_wrapped_passphrase_into_keyring.c,
    src/utils/ecryptfs-migrate-home, src/utils/ecryptfs-mount-private,
    src/utils/ecryptfs-recover-private,
    src/utils/ecryptfs_rewrap_passphrase.c, src/utils/ecryptfs-rewrite-
    file, src/utils/ecryptfs-setup-private, src/utils/ecryptfs-setup-
    swap, src/utils/ecryptfs-umount-private,
    src/utils/ecryptfs_unwrap_passphrase.c,
    src/utils/ecryptfs_wrap_passphrase.c:
    - update some email addresses, moving kirkland@xxxxxxxxxxxxx ->
      kirkland@xxxxxxxxxx (which I can still read)
  * src/libecryptfs/key_management.c: LP: #715066
    - fix 2 places where we were handling
      ecryptfs_add_passphrase_key_to_keyring() inconsistently
    - if we're trying to add a key to the keyring, and it's already there,
      treat that as "success"
  * debian/control:
    - ecryptfs-setup-swap is strongly recommended, which depends on
      cryptsetup; so promote cryptsetup from suggests -> recommends
  * precise

  [ Stephan Ritscher and Tyler Hicks ]
  * src/libecryptfs/cmd_ln_parser.c: LP: #683535
    - fix passphrase_passwd_fd for pipes
    - handle memory allocation failures
    - free memory in error paths

  [ Arfrever Frehtes Taifersar Arahesis ]
  * configure.ac: LP: #893327
    - no need to check for python, if --disable-pywrap is passed
 -- Dustin Kirkland <dustin.kirkland@xxxxxxxxxxx>   Wed, 14 Dec 2011 11:49:10 -0600

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

-- 
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 Released

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