It was reported [1] that the private ecryptfs mount helper (/sbin/mount.ecryptfs_private), which is setuid-root, could allow an unprivileged local user to mount user-controlled ecryptfs shares on the local system. Because the ecryptfs helper does not mount filesystems with the "nosuid" and "nodev" flags, it would be possible for a user to mount a filesystem containing setuid-root binaries and/or device files that could lead to the escalation of their privileges. This could be done via a USB device, if the user had physical access to the system. It was however also noted [2] that this may only affect version 86 and later, as the encrypted home source and destination mount points were hard-coded up until that version. Forcing MS_NOSUID and MS_NODEV mount flags was added to version 99 (commits [3],[4]) [1] http://www.openwall.com/lists/oss-security/2012/07/10/19 [2] http://www.openwall.com/lists/oss-security/2012/07/11/2 [3] http://bazaar.launchpad.net/~ecryptfs/ecryptfs/trunk/revision/705 [4] http://bazaar.launchpad.net/~ecryptfs/ecryptfs/trunk/revision/708
I also forgot to note that on Fedora and RHEL, you need to be part of the ecryptfs group to even use the ecryptfs filesystems/utilities, which lowers the attack surface considerably.
Statement: Not Vulnerable. This issue does not affect the version of ecryptfs-utils as shipped with Red Hat Enterprise Linux 5 and 6.
Created ecryptfs-utils tracking bugs for this issue Affects: fedora-all [bug 842512]
ecryptfs-utils-99-1.fc17 has been pushed to the Fedora 17 stable repository. If problems still persist, please make note of it in this bug report.
ecryptfs-utils-99-1.fc16 has been pushed to the Fedora 16 stable repository. If problems still persist, please make note of it in this bug report.