• Jann Horn's avatar
    fs: if a coredump already exists, unlink and recreate with O_EXCL · fbb18169
    Jann Horn authored
    
    
    It was possible for an attacking user to trick root (or another user) into
    writing his coredumps into an attacker-readable, pre-existing file using
    rename() or link(), causing the disclosure of secret data from the victim
    process' virtual memory.  Depending on the configuration, it was also
    possible to trick root into overwriting system files with coredumps.  Fix
    that issue by never writing coredumps into existing files.
    
    Requirements for the attack:
     - The attack only applies if the victim's process has a nonzero
       RLIMIT_CORE and is dumpable.
     - The attacker can trick the victim into coredumping into an
       attacker-writable directory D, either because the core_pattern is
       relative and the victim's cwd is attacker-writable or because an
       absolute core_pattern pointing to a world-writable directory is used.
     - The attacker has one of these:
      A: on a system with protected_hardlinks=0:
         execute access to a folder containing a victim-owned,
         attacker-readable file on the same partition as D, and the
         victim-owned file will be deleted before the main part of the attack
         takes place. (In practice, there are lots of files that fulfill
         this condition, e.g. entries in Debian's /var/lib/dpkg/info/.)
         This does not apply to most Linux systems because most distros set
         protected_hardlinks=1.
      B: on a system with protected_hardlinks=1:
         execute access to a folder containing a victim-owned,
         attacker-readable and attacker-writable file on the same partition
         as D, and the victim-owned file will be deleted before the main part
         of the attack takes place.
         (This seems to be uncommon.)
      C: on any system, independent of protected_hardlinks:
         write access to a non-sticky folder containing a victim-owned,
         attacker-readable file on the same partition as D
         (This seems to be uncommon.)
    
    The basic idea is that the attacker moves the victim-owned file to where
    he expects the victim process to dump its core.  The victim process dumps
    its core into the existing file, and the attacker reads the coredump from
    it.
    
    If the attacker can't move the file because he does not have write access
    to the containing directory, he can instead link the file to a directory
    he controls, then wait for the original link to the file to be deleted
    (because the kernel checks that the link count of the corefile is 1).
    
    A less reliable variant that requires D to be non-sticky works with link()
    and does not require deletion of the original link: link() the file into
    D, but then unlink() it directly before the kernel performs the link count
    check.
    
    On systems with protected_hardlinks=0, this variant allows an attacker to
    not only gain information from coredumps, but also clobber existing,
    victim-writable files with coredumps.  (This could theoretically lead to a
    privilege escalation.)
    Signed-off-by: default avatarJann Horn <jann@thejh.net>
    Cc: Kees Cook <keescook@chromium.org>
    Cc: Al Viro <viro@zeniv.linux.org.uk>
    Signed-off-by: default avatarAndrew Morton <akpm@linux-foundation.org>
    Signed-off-by: default avatarLinus Torvalds <torvalds@linux-foundation.org>
    fbb18169
coredump.c 19.1 KB