ecryptfs team mailing list archive

[segooon <732614@xxxxxxxxxxxxxxxxxx>]

*** This bug is a security vulnerability ***

Private security bug reported:

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.

** 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 (Debian)
   Importance: Undecided
       Status: New

** Also affects: ecryptfs-utils (Fedora)
   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/732614

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

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:
  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.