users can DoS one another from mounting their encrypted private or home directories

Bug #402745 reported by Dustin Kirkland  on 2009-07-21
This bug affects 1 person
Affects Status Importance Assigned to Milestone
ecryptfs-utils (Ubuntu)
Dustin Kirkland 
Dustin Kirkland 
Dustin Kirkland 

Bug Description

Binary package hint: ecryptfs-utils

The eCryptfs encrypted-private and encrypted-home features use a counter file, usually /tmp/ecryptfs-$USER-Private, to account for the number of times a mount/unmount occurs.

Since this file is in /tmp, one user can DoS another user from accessing their data, if they create the file before the other user does.


Dustin Kirkland  (kirkland) wrote :

Fix committed in r421 and r422.

This should perhaps be SRU'd to Jaunty. I'll defer that decision to the Security Team.


Changed in ecryptfs-utils (Ubuntu):
status: New → Fix Committed
importance: Undecided → High
assignee: nobody → Dustin Kirkland (kirkland)
Changed in ecryptfs-utils (Ubuntu Jaunty):
status: New → Triaged
importance: Undecided → High
assignee: nobody → Dustin Kirkland (kirkland)
Changed in ecryptfs:
status: New → Fix Committed
importance: Undecided → High
Launchpad Janitor (janitor) wrote :

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

ecryptfs-utils (77-0ubuntu1) karmic; urgency=low

  [ Dustin Kirkland ]
  * src/libecryptfs/key_management.c, src/pam_ecryptfs/pam_ecryptfs.c:
    revert the zombie code removal from pam_ecryptfs as it seems this
    bit is still needed; fix the source of the problem introduced in
    commit r407; check for non-zero return codes; this problem would
    manifest itself as a) unable to unlock screensaver, b) unable to
    switch users, c) unable to mount home folder on initial login;
    LP: #402222, #402029
  * src/utils/ecryptfs-umount-private: use for loop to loop over key
    ids on removal
  * src/utils/mount.ecryptfs_private.c: return non-zero on unmount failure
    due to open sessions; handle this in ecryptfs-umount-private too; make
    the flock() blocking; use /dev/shm for counter; add an iterator to the
    counter file to prevent users from DoS'ing one another from accessing
    their encrypted directories, LP: #402745
  * debian/ecryptfs-utils.postinst: move /tmp counters to /dev/shm
  * link against pam, silence shlib warning
  * src/include/ecryptfs.h, src/libecryptfs/main.c,
    src/pam_ecryptfs/pam_ecryptfs.c, src/utils/,
    src/utils/mount.ecryptfs_private.c: move two functions from
    mount.ecryptfs_private to libecryptfs, namely is_mounted() and
    fetch_private_mnt(); use these in both pam_ecryptfs and
    mount.ecryptfs_private; also move PRIVATE to ECRYPTFS_PRIVATE in
    the ecryptfs.h headers; this will allow us to short-circuit some of the
    costly key-loading code on pam_auth if the private dir is already
    mounted, speeding up some subsequent authentications significantly,
    LP: #402748
  * doc/ecryptfs-mount-private.txt: removed the "$" to make copy-n-paste
    more user friendly
  * src/utils/ecryptfs-setup-private: when encrypting home, put the
    .ecryptfs and .Private data in /home/.ecryptfs rather than /var/lib,
    as users are forgetting to backup /var/lib, and are often putting
    /home on a separate partition; furthermore, this gives users a place
    to access their encrypted data for backup, rather than hiding the
    data below $HOME, LP: #371719

  [ Tyler Hicks ]
  * src/libecryptfs/cipher_list.c, src/libecryptfs/module_mgr.c:
    add blowfish/56-bytes to the list of ciphers we officially support,
    LP: #402790

 -- Dustin Kirkland <email address hidden> Wed, 22 Jul 2009 00:01:56 -0500

Changed in ecryptfs-utils (Ubuntu Karmic):
status: Fix Committed → Fix Released
Changed in ecryptfs:
status: Fix Committed → Fix Released
Jamie Strandboge (jdstrand) wrote :

Thank you for reporting this bug to Ubuntu. jaunty has reached EOL
(End of Life) and is no longer supported. As a result, this bug
against jaunty is being marked "Won't Fix". Please see for currently supported Ubuntu

Please feel free to report any other bugs you may find.

Changed in ecryptfs-utils (Ubuntu Jaunty):
status: Triaged → Won't Fix
visibility: private → public
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