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?