Skip to content

L
linux
Switch branch/tag
  1. 08 Jun, 2016 3 commits
    • Jann Horn's avatar
      UBUNTU: SAUCE: ecryptfs: forbid opening files without mmap handler · 51982ff9
      Jann Horn authored 
      BugLink: http://bugs.launchpad.net/bugs/1588871

This prevents users from triggering an exploitable stack overflow
through a recursive invocation of pagefault handling on systems that
allow unprivileged users to mount ecryptfs. More precisely:

When a file in ecryptfs is mmap()ed, ecryptfs only uses the VFS read
and write methods of the lower filesystem (using kernel_read() and
kernel_write()) to interact with the lower file. This means that
it is possible to mmap() the decrypted view of a lower file that
normally couldn't be mmap()ed.

One such file is /proc/$pid/environ. If an encrypted ecryptfs file
is placed in the environment area of a process with PID $pid and
/proc/$pid is mounted to /tmp/foo, /tmp/foo/environ can then be
opened and mmap()ed. A pagefault in the memory area to which
/tmp/foo/environ is mapped will cause a kernel_read() on
/proc/$pid/environ, which in turn will cause a pagefault in the
context of the process with PID $pid.

By using a chain of processes in which each process has the
decrypted view of the next process' environment mapped into its
environment area, where the environment of the last process in the
chain is an "ecryptfs matroska" (the result of encrypting some data
using ecryptfs, then encrypting the result of that and so on), and
then triggering a pagefault in the environment of the first process
in the chain, it is possible to cause a recursive pagefault that
ends up overflowing the stack.

Fix it by disallowing opening anything without an mmap handler
through ecryptfs.

CVE-2016-1583
Signed-off-by: default avatarJann Horn <jannh@google.com>
Cc: stable@vger.kernel.org
Acked-by: default avatarTyler Hicks <tyhicks@canonical.com>
Acked-by: default avatarLuis Henriques <luis.henriques@canonical.com>
Signed-off-by: default avatarKamal Mostafa <kamal@canonical.com>
      51982ff9
    • Jann Horn's avatar
      UBUNTU: SAUCE: proc: prevent stacking filesystems on top · b5b2e27c
      Jann Horn authored 
      BugLink: http://bugs.launchpad.net/bugs/1588871

This prevents stacking filesystems (ecryptfs and overlayfs)
from using procfs as lower filesystem. There is too much magic
going on inside procfs, and there is no good reason to stack
stuff on top of procfs.

(For example, procfs does access checks in VFS open handlers,
and ecryptfs by design calls open handlers from a kernel
thread that doesn't drop privileges or so.)
Signed-off-by: default avatarJann Horn <jannh@google.com>
Cc: stable@vger.kernel.org
CVE-2016-1583
Acked-by: default avatarTyler Hicks <tyhicks@canonical.com>
Acked-by: default avatarLuis Henriques <luis.henriques@canonical.com>
Signed-off-by: default avatarKamal Mostafa <kamal@canonical.com>
      b5b2e27c
    • Al Viro's avatar
      ecryptfs: fix handling of directory opening · 1be0aa47
      Al Viro authored 
      First of all, trying to open them r/w is idiocy; it's guaranteed to fail.
Moreover, assigning ->f_pos and assuming that everything will work is
blatantly broken - try that with e.g. tmpfs as underlying layer and watch
the fireworks.  There may be a non-trivial amount of state associated with
current IO position, well beyond the numeric offset.  Using the single
struct file associated with underlying inode is really not a good idea;
we ought to open one for each ecryptfs directory struct file.

Additionally, file_operations both for directories and non-directories are
full of pointless methods; non-directories should *not* have ->iterate(),
directories should not have ->flush(), ->fasync() and ->splice_read().
Signed-off-by: default avatarAl Viro <viro@zeniv.linux.org.uk>
(cherry picked from commit 6a480a78)
Acked-by: default avatarJohn Johansen <john.johansen@canonical.com>
Signed-off-by: default avatarLuis Henriques <luis.henriques@canonical.com>
Signed-off-by: default avatarAndy Whitcroft <apw@canonical.com>
      1be0aa47
  3. 03 Jun, 2016 1 commit
  5. 19 May, 2016 1 commit
  7. 16 May, 2016 35 commits
GitLab Nexedi Edition | About GitLab | About Nexedi | 沪ICP备2021021310号-2 | 沪ICP备2021021310号-7