Why are PID suffixed temporary files a vulnerability

Question

Why is this a security issue?

> https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=820331
>
> very predictable temporary files (like
> /tmp/cronic.out.$$) that depends only on PID:

> OUT=/tmp/cronic.out.$$
> ERR=/tmp/cronic.err.$$
> TRACE=/tmp/cronic.trace.$$

> "$@" >$OUT 2>$TRACE

Use CVE-2016-3992.

Security through obscurity never slows down modern hacking software and always makes debugging harder.

With the /tmp directory always having sticky bit set (drwxrwxrwt), doesn't that prevent deletion and replacement by a malicious user?

Update 2016-05-08

Based on Lie Ryan's Answer, have experimented with the following results...

System
  Puppy Linux 5.2.8 (based on Ubuntu 10.04)

Privileged User
  root
    /etc/passwd
      root:x:0:0:root:/root:/bin/bash
    $PATH
      :/root/bin::/src/bin:/root/bin:/bin:/usr/bin: ...
    > groups root
      root : root tty
    > id -nG root
      root tty

Unprivileged User
  spot
    /etc/passwd
      spot:x:502:502:Linux User,,,:/home/spot:/bin/sh
    $PATH
      :/root/bin::/src/bin:/root/bin:/bin:/usr/bin: ...
    > groups spot
      spot : spot
    > id -nG spot
      spot

Owners, Groups, Permissions
  > ls -l /bin/busybox /bin/cat
    -rwxr-x--- 1 root root 637960 2011-08-17 11:04 /bin/busybox
    -rwxr-xr-x 1 root root  50820 2011-08-17 11:04 /bin/cat

  > ls -l /usr/bin/less
    lrwxrwxrwx 1 root root 17 2011-08-17 10:49 /usr/bin/less -> ../../bin/busybox

  > ls -l /home/spot/myless /home/spot/text
    lrwxrwxrwx 1 spot spot 13 2016-05-08 12:23 /home/spot/myless -> /usr/bin/less
    -rw-r--r-- 1 spot spot 12 2016-05-08 13:01 /home/spot/text

Expected Behavior
  Thus, unprivileged user 'spot' should be able to run 'cat', but not 'less'.

Attempt to run 'less' via the symlink (indented for clarity)

  root@LX03:~  su spot     

  spot@LX03:~  pwd
    /home/spot

  spot@LX03:~  echo $PATH
    :/root/bin::/src/bin:/root/bin:/bin:/usr/bin: ...

  spot@LX03:~  ls -l myless text
    lrwxrwxrwx 1 spot spot 13 2016-05-08 12:23 myless -> /usr/bin/less
    -rw-r--r-- 1 spot spot 12 2016-05-08 13:01 text

  spot@LX03:~  cat text
    sample text

  spot@LX03:~  myless text
    sh: ./myless: Permission denied

If I understand correctly, the vulnerability of tmp files with pid suffixes would be of a malicious program creating "a symlink to a privileged file" (presumedly an executable) in order to be able to run it, though the owner of the malicious program does not otherwise have the permissions needed to do so. Is this a correct understanding?

If so, I'm missing something.

Ownership, group and permissions (OGPs) are on the actual file, not the directory entry. A symlink is a directory entry pointing to another directory entry.

I don't understand how a symlink can open a vulnerability.

As I understand it, and my experiments support, OGPs are global to the entire filesystem regardless how a file is located. It doesn't matter if the file is accessed by a symlink, by searching the $PATH directories or entering the entire path directly.

The only way I see an executable can be used to access directories and files that the executable's owner has access to, but the user running it does not, is if the executable has SETUID or SETGID enabled.

What am I misunderstanding?

Answer 1

The issue is that the attacker can create a symlink before a vulnerable program can. For example, you could write a script that watches the process list, and as soon as a program with the right name shows up in the list, the script would race to create a symlink to a privileged file before the vulnerable program can. If the vulnerable program is running as privileged process (as cronjobs often are), this may allow the attacker to write to files that the attacker doesn't have privileges to write to.

In some cases, you can even start creating the symlinks before the program even started, because PID is assigned sequentially and if you know that another program always/often starts before the vulnerable program starts, you can preemptively create a few PID files ahead of time.

Once the file is created, the vulnerability isn't an issue because of the sticky bit.