4.35. ecryptfs-utils

Security Fixes

CVE-2011-1831

The setuid mount.ecryptfs_private utility allows users to mount an eCryptfs file system. This utility can only be run by users in the "ecryptfs" group.

A race condition flaw was found in the way mount.ecryptfs_private checked the permissions of a requested mount point when mounting an encrypted file system. A local attacker could possibly use this flaw to escalate their privileges by mounting over an arbitrary directory.

CVE-2011-1832

A race condition flaw in umount.ecryptfs_private could allow a local attacker to unmount an arbitrary file system.

CVE-2011-1834

It was found that mount.ecryptfs_private did not handle certain errors correctly when updating the mtab (mounted file systems table) file, allowing a local attacker to corrupt the mtab file and possibly unmount an arbitrary file system.

CVE-2011-1835

An insecure temporary file use flaw was found in the ecryptfs-setup-private script. A local attacker could use this script to insert their own key that will subsequently be used by a new user, possibly giving the attacker access to the user's encrypted data if existing file permissions allow access.

CVE-2011-1837

A race condition flaw in mount.ecryptfs_private could allow a local attacker to overwrite arbitrary files.

CVE-2011-3145

A race condition flaw in the way temporary files were accessed in mount.ecryptfs_private could allow a malicious, local user to make arbitrary modifications to the mtab file.

CVE-2011-1833

A race condition flaw was found in the way mount.ecryptfs_private checked the permissions of the directory to mount. A local attacker could use this flaw to mount (and then access) a directory they would otherwise not have access to. Note: The fix for this issue is incomplete until a kernel-space change is made. Future Red Hat Enterprise Linux 5 and 6 kernel updates will correct this issue.

BZ#554740

Previously, the eCryptfs daemon, ecryptfsd, failed to start if the ecryptfs kernel module had not already created the files necessary for user space communication under the /dev/ and /dev/misc/ directories, and "No such file or directory" messages were logged. This update avoids this race condition by ensuring that the ecryptfsd daemon waits and then attempts to start again if it discovers that the requisite files have not yet been created.

BZ#553629

Prior to this update ecryptfs did not correctly handle the salt option together with the password file. As a result mounting of the encrypted file system would fail and the error, "Bad address", would be displayed. With this update ecryptfs correctly handles the salt option and mounting of the encrypted file system using eCryptfs no longer fails.