ecryptfs team mailing list archive

[Curtis Hovey <curtis.hovey@xxxxxxxxxxxxx>]

** No longer affects: ecryptfs-utils (Fedora)

-- 
You received this bug notification because you are a member of eCryptfs,
which is subscribed to the bug report.
https://bugs.launchpad.net/bugs/732614

Title:
  pam_ecryptfs doesn't drop gid when using user's files

Status in eCryptfs - Enterprise Cryptographic Filesystem:
  Triaged
Status in “ecryptfs-utils” package in Ubuntu:
  Triaged
Status in “ecryptfs-utils” package in Debian:
  New

Bug description:
  I report several bug as a single ticket as they have approximately the
  same significance and it's more simple to fix them at a time.

  1) pam_ecryptfs heavily use non-root files, dropping EUID=0, but
  forgets to drop EGID=0.  To exploit it try to create symlink
  ~/.ecryptfs/auto-mount to some existing (not not visible to nonroot)
  root owned file, run inotifywait on ~/.ecryptfs/ and try to login as a
  user, triggering pam_ecryptfs code.  Then compare with nonexisting
  root file.

  Some filesystem syscalls are used with EUID=0: inside of
  ecryptfs_pam_automount_set(), ecryptfs_fetch_private_mnt(),
  ecryptfs_read_salt_hex_from_rc().

  2) It runs (u)mount.ecryptfs_private with GID=0.
  mount.ecryptfs_private drops only UID, so it becomes vulnerable to
  leakage of existence of files with group=root, like (1).

  3) All results of set*id() syscalls must be checked not to repeat
  sendmail bug.  There is actually one real bug with not checking return
  code: wrap_passphrase_if_necessary() calls setuid() (not seteuid()!)
  and doesn't restore full root.

  4) generate_nv_list() calls strlen() with argument to user
  controllable data. The data might be not terminating with \0.  This
  may lead to SEGFAULT.

  5) src/libecryptfs/key_management.c calls read(), but doesn't check
  how many bytes were read. This might lead to a leakage of contents of
  stack memory of privileged process.

  
  Note that (2) may not be fixed by dropping gid=0 with setresgid() as the process would become ptrace'able.  As it still owns root-owned tty, etc., this would lead to privilege escalation.

To manage notifications about this bug go to:
https://bugs.launchpad.net/ecryptfs/+bug/732614/+subscriptions