Polkit temporary auth hijacking via pid reuse and nonatomic fork Vulnerability / Exploit
/
/
/
Exploits / Vulnerability Discovered : 2019-01-09 |
Type : dos |
Platform : linux
This exploit / vulnerability Polkit temporary auth hijacking via pid reuse and nonatomic fork is for educational purposes only and if it is used you will do on your own risk!
[+] Code ...
/*
When a (non-root) user attempts to e.g. control systemd units in the system
instance from an active session over DBus, the access is gated by a polkit
policy that requires "auth_admin_keep" auth. This results in an auth prompt
being shown to the user, asking the user to confirm the action by entering the
password of an administrator account.
After the action has been confirmed, the auth decision for "auth_admin_keep" is
cached for up to five minutes. Subject to some restrictions, similar actions can
then be performed in this timespan without requiring re-auth:
- The PID of the DBus client requesting the new action must match the PID of
the DBus client requesting the old action (based on SO_PEERCRED information
forwarded by the DBus daemon).
- The "start time" of the client's PID (as seen in /proc/$pid/stat, field 22)
must not have changed. The granularity of this timestamp is in the
millisecond range.
- polkit polls every two seconds whether a process with the expected start time
still exists. If not, the temporary auth entry is purged.
Without the start time check, this would obviously be buggy because an attacker
could simply wait for the legitimate client to disappear, then create a new
client with the same PID.
Unfortunately, the start time check is bypassable because fork() is not atomic.
Looking at the source code of copy_process() in the kernel:
if (pid != &init_struct_pid) {
pid = alloc_pid(p->nsproxy->pid_ns_for_children);
if (IS_ERR(pid)) {
retval = PTR_ERR(pid);
goto bad_fork_cleanup_thread;
}
}
The ktime_get_boot_ns() call is where the "start time" of the process is
recorded. The alloc_pid() call is where a free PID is allocated. In between
these, some time passes; and because the copy_thread_tls() call between them can
access userspace memory when sys_clone() is invoked through the 32-bit syscall
entry point, an attacker can even stall the kernel arbitrarily long at this
point (by supplying a pointer into userspace memory that is associated with a
userfaultfd or is backed by a custom FUSE filesystem).
This means that an attacker can immediately call sys_clone() when the victim
process is created, often resulting in a process that has the exact same start
time reported in procfs; and then the attacker can delay the alloc_pid() call
until after the victim process has died and the PID assignment has cycled
around. This results in an attacker process that polkit can't distinguish from
the victim process.
I have attached a reproducer as slowfork.c. Usage:
Compile:
$ gcc -o slowfork slowfork.c -pthread -O2
As user A, run it:
$ ./slowfork
No output appears at this point.
As user B, run "systemctl stop cups.service". When the auth prompt comes up,
wait a few seconds, then enter the required password.
If the attack worked, user A should show see something like this:
======
got uffd msg
good pagefault
old start time: 2454277
awaiting death of 16466...
cycling...
cycling done
cycling...
cycling done
scanning for previous free PID
looping PID (going for 16465)
resolving pagefault
clone result (positive): 16466
new start time: 2454277
child died, exiting
======
cups.service should be running afterwards because the PoC running as user A
restarted it.
Sometimes the attack fails because the start time of the attacker process is off
by one ("old start time" and "new start time" don't match); in that case, user
A will get an auth popup. It tends to work after a few tries for me.
(The attack would likely work much more reliably if the PoC triggered the
sys_clone() on victim process creation; at the moment, it only triggers when the
victim process calls execve().)