mount.ecryptfsprivate.c in eCryptfs-utils does not validate mount destination filesystem types, which allows local users to gain privileges by mounting over a nonstandard filesystem, as demonstrated by /proc/$pid.

ecryptfs-utils: suid helper does not restrict mounting filesystems with nosuid,nodev which creates a possible privilege escalation

The (1) ecryptfs-setup-private, (2) ecryptfs-setup-confidential, and (3) ecryptfs-setup-pam-wrapped.sh scripts in ecryptfs-utils 45 through 61 in eCryptfs place cleartext passwords on command lines, which allows local users to obtain sensitive information by listing the process.

eCryptfs 104 and earlier uses a default salt to encrypt the mount passphrase, which makes it easier for attackers to obtain user passwords via a brute force attack.

A number of flaws were reported [1] in eCryptfs that could allow a user to mount or unmount arbitrary locations, and possibly disclose confidential information:

Vasiliy Kulikov of Openwall and Dan Rosenberg discovered that eCryptfs incorrectly validated permissions on the requested mountpoint. A local attacker could use this flaw to mount to arbitrary locations, leading to privilege escalation. (CVE-2011-1831)

Vasiliy Kulikov of Openwall and Dan Rosenberg discovered that eCryptfs incorrectly validated permissions on the requested mountpoint. A local attacker could use this flaw to unmount to arbitrary locations, leading to a denial of service. (CVE-2011-1832)

Vasiliy Kulikov of Openwall and Dan Rosenberg discovered that eCryptfs incorrectly validated permissions on the requested source directory. A local attacker could use this flaw to mount an arbitrary directory, possibly leading to information disclosure. Note that this flaw also requires a fix in the kernel to be complete. (CVE-2011-1833)

Dan Rosenberg and Marc Deslauriers discovered that eCryptfs incorrectly handled modifications to the mtab file when an error occurs. A local attacker could use this flaw to corrupt the mtab file, and possibly unmount arbitrary locations, leading to a denial of service. (CVE-2011-1834)

Marc Deslauriers discovered that eCryptfs incorrectly handled keys when setting up an encrypted private directory. A local attacker could use this flaw to manipulate keys during creation of a new user. (CVE-2011-1835)

Marc Deslauriers discovered that eCryptfs incorrectly handled permissions during recovery. A local attacker could use this flaw to possibly access another user's data during the recovery process. (CVE-2011-1836)

Vasiliy Kulikov of Openwall discovered that eCryptfs incorrectly handled lock counters. A local attacker could use this flaw to possibly overwrite arbitrary files. (CVE-2011-1837)

[1] https://launchpad.net/bugs/732628

Last updated 24 July 2024

Last updated 24 July 2024

Last updated 24 July 2024

ecryptfs-setup-swap in eCryptfs before 111 does not prevent the unencrypted swap partition from activating during boot when using GPT partitioning and certain versions of systemd, which allows local users to obtain sensitive information via unspecified vectors.

ecryptfs-setup-swap in eCryptfs does not prevent the unencrypted swap partition from activating during boot when using GPT partitioning on a (1) NVMe or (2) MMC drive, which allows local users to obtain sensitive information via unspecified vectors. NOTE: this vulnerability exists because of an incomplete fix for CVE-2015-8946.

Last updated 24 July 2024

Last updated 24 July 2024