*** This bug is a security vulnerability ***
Private security bug reported:
check_ownerships() function doesn't work as it should because of a race
condition. Arguments of both mount() and umount() calls can be changed
between the check and the usage. This may lead to arbitrary mount point
umounting or probably to gaining ability to try passphrases of
otherpeople's ecryptfs storages.
lock_counter() is also racy. It (1) tries to check existance and
ownership of the file before open(), (2) neither use stat() instead of
lstat() nor O_NOFOLLOW, (3) is not protected against deletion of the
lock file by the owner. The lock file should be probably created in root
only writable directory before dropping EUID.
** Affects: ecryptfs
Importance: Undecided
Status: New
** Affects: ecryptfs-utils (Ubuntu)
Importance: Undecided
Status: New
** Affects: ecryptfs-utils (Debian)
Importance: Undecided
Status: New
** Affects: ecryptfs-utils (Fedora)
Importance: Undecided
Status: New
** Also affects: ecryptfs-utils (Ubuntu)
Importance: Undecided
Status: New
** Also affects: ecryptfs-utils (Fedora)
Importance: Undecided
Status: New
** Also affects: ecryptfs-utils (Debian)
Importance: Undecided
Status: New
--
You received this bug notification because you are a member of eCryptfs,
which is a direct subscriber.
https://bugs.launchpad.net/bugs/732628
Title:
TOCTOU in mount.ecryptfs_private
Status in eCryptfs - Enterprise Cryptographic Filesystem:
New
Status in “ecryptfs-utils” package in Ubuntu:
New
Status in “ecryptfs-utils” package in Debian:
New
Status in “ecryptfs-utils” package in Fedora:
New
Bug description:
check_ownerships() function doesn't work as it should because of a
race condition. Arguments of both mount() and umount() calls can be
changed between the check and the usage. This may lead to arbitrary
mount point umounting or probably to gaining ability to try
passphrases of otherpeople's ecryptfs storages.
lock_counter() is also racy. It (1) tries to check existance and
ownership of the file before open(), (2) neither use stat() instead of
lstat() nor O_NOFOLLOW, (3) is not protected against deletion of the
lock file by the owner. The lock file should be probably created in
root only writable directory before dropping EUID.
_______________________________________________
Mailing list: https://launchpad.net/~ecryptfs
Post to : [email protected]
Unsubscribe : https://launchpad.net/~ecryptfs
More help : https://help.launchpad.net/ListHelp
