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.
/tmp directory always having sticky bit set (drwxrwxrwt), doesn't that prevent deletion and replacement by a malicious user?
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?