ecryptfs team mailing list archive

[Dustin Kirkland <dustin.kirkland@xxxxxxxxx>]

Thanks for the report.  Will get these fixed.

** Changed in: ecryptfs
       Status: New => Triaged

** Changed in: ecryptfs
   Importance: Undecided => High

** Changed in: ecryptfs
     Assignee: (unassigned) => Dustin Kirkland (kirkland)

** Changed in: ecryptfs-utils (Ubuntu)
       Status: New => Triaged

** Changed in: ecryptfs-utils (Ubuntu)
   Importance: Undecided => High

** Changed in: ecryptfs-utils (Ubuntu)
     Assignee: (unassigned) => Dustin Kirkland (kirkland)

-- 
You received this bug notification because you are a member of eCryptfs,
which is a direct subscriber.
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
Status in “ecryptfs-utils” package in Fedora:
  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.