New issue
Advanced search Search tips
Starred by 2 users

Issue metadata

Status: Fixed
Closed: Jan 9

Sign in to add a comment

Issue 1692: polkit: temporary auth hijacking via PID reuse and non-atomic fork

Reported by, Oct 10 Project Member

Issue description

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:

        p->start_time = ktime_get_ns();
        p->real_start_time = ktime_get_boot_ns();
        retval = copy_thread_tls(clone_flags, stack_start, stack_size, p, tls);
        if (retval)
                goto bad_fork_cleanup_io;

        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:


    $ 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 done
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().)

Tested on Ubuntu 18.04.

This bug is subject to a 90 day disclosure deadline. After 90 days elapse
or a patch has been made broadly available (whichever is earlier), the bug
report will become visible to the public.
7.0 KB View Download

Comment 1 by, Jan 8

Project Member
Labels: -Restrict-View-Commit Deadline-Exceeded
Deadline exceeded -- automatically derestricting

Comment 2 by, Jan 8

Project Member
As far as I understand, a fix for this should land in sometime later today.
Additionally, a kernel fix that mitigates this issue is queued up in Linus' tree:

Comment 4 by, Jan 9

Project Member
Status: Fixed (was: New)
Fix has landed on the master branch:

Comment 5 by, Jan 14

CVE-2019-6133 I think.

Comment 6 by, Jan 14

Project Member
Labels: CVE-2019-6133

Sign in to add a comment