Hi Paul, Markus followed already up, I just want to give some additional comments on the below:
On Fri, Oct 14, 2016 at 07:07:52PM +1100, paul.sz...@sydney.edu.au wrote: > Dear Salvatore, > > > ... if the attacher created a symlink between the rm and the mkdir > > then mkdir will still fail with -p on a symlink. (Or do I miss > > something?). ... > > Yes, you missed a simple test: > > $ mkdir mydir > $ ln -s mydir mylink > $ ls -ld my* > drwx------ 2 psz amstaff 4096 Oct 14 18:46 mydir > lrwxrwxrwx 1 psz amstaff 5 Oct 14 18:46 mylink -> mydir > $ mkdir -p mylink || echo failed > $ mkdir -p mylink; echo $? > 0 > $ mkdir mylink || echo failed > mkdir: cannot create directory `mylink': File exists > failed > $ mkdir mylink; echo $? > mkdir: cannot create directory `mylink': File exists > 1 > $ ls -ld my* > drwx------ 2 psz amstaff 4096 Oct 14 18:46 mydir > lrwxrwxrwx 1 psz amstaff 5 Oct 14 18:46 mylink -> mydir > $ > > showing that "mkdir -p" does not fail (but plain mkdir does). You are doing all the tests with the same user. But yes mkdir -p will succeed for the root user still in some cases. Let's recapitulate your described attack. The attacker has shell-access on the tomcat8 running host or by other mean can run code on the server by an unprivileged user and used inotify to detect when $JVM_TMP will be removed. Let's say the tomcat8 service is started. JVM_TMP=/tmp/tomcat8-tomcat8-tmp # rm -rf "$JVM_TMP". With inotify the evil user detects, that /tmp/tomcat8-tomcat8-tmp got removed and has several options for proceeding. Either create a directory, or directly a malicious symlink. evil@jessie:~$ ln -s /etc/passwd /tmp/tomcat8-tomcat8-tmp evil@jessie:~$ ls -l /tmp/tomcat8-tomcat8-tmp lrwxrwxrwx 1 evil evil 11 Oct 14 20:20 /tmp/tomcat8-tomcat8-tmp -> /etc/passwd evil@jessie:~$ raced before root will issue the mkdir -p call: root@jessie# mkdir -p /tmp/tomcat8-tomcat8-tmp mkdir: cannot create directory ‘/tmp/tomcat8-tomcat8-tmp’: File exists root@jessie# echo $? 1 root@jessie# if the evil user instead created a directory, then yes you are right for that part: evil@jessie$ mkdir -p /tmp/tomcat8-tomcat8-tmp evil@jessie$ ls -ld /tmp/tomcat8-tomcat8-tmp drwxr-xr-x 2 evil evil 4096 Oct 14 20:25 /tmp/tomcat8-tomcat8-tmp evil@jessie$ followed by the root user root@jessie# mkdir -p /tmp/tomcat8-tomcat8-tmp root@jessie# echo $? 0 root@jessie# If now the evil user wins again the race, and removes the directory in time and replaces it with the symlink to a desired file to overwrite, before the chown call of the root user: evil@jessie$ rmdir /tmp/tomcat8-tomcat8-tmp evil@jessie$ ln -s /etc/passwd /tmp/tomcat8-tomcat8-tmp evil@jessie$ ls -l /tmp/tomcat8-tomcat8-tmp lrwxrwxrwx 1 evil evil 11 Oct 14 20:28 /tmp/tomcat8-tomcat8-tmp -> /etc/passwd evil@jessie$ root@jessie# chown tomcat8 /tmp/tomcat8-tomcat8-tmp chown: cannot dereference ‘/tmp/tomcat8-tomcat8-tmp’: Permission denied root@jessie# echo $? 1 root@jessie# ls -l /etc/passwd -rw-r--r-- 1 root root 1631 Oct 14 20:07 /etc/passwd root@jessie# The same if the evil user created a symlink to a existing directory: evil@jessie$ ln -sf /etc /tmp/tomcat8-tomcat8-tmp evil@jessie$ ls -l /tmp/tomcat8-tomcat8-tmp lrwxrwxrwx 1 evil evil 4 Oct 14 21:01 /tmp/tomcat8-tomcat8-tmp -> /etc evil@jessie$ root@jessie# mkdir -p /tmp/tomcat8-tomcat8-tmp mkdir: cannot create directory ‘/tmp/tomcat8-tomcat8-tmp’: File exists root@jessie# root@jessie# chown tomcat8 /tmp/tomcat8-tomcat8-tmp chown: cannot dereference ‘/tmp/tomcat8-tomcat8-tmp’: Permission denied root@jessie# because of the kernel hardening. > > On the practicality for Debian systems though this is mitigated by the > > Kernel hardenings which are enabled by default: > > > > fs.protected_hardlinks=1 > > fs.protected_symlink=1 > > > > which will prevent that the target of the symlink in /tmp will be > > changed on the chown call. > > Another missing test (besides: who is changing anything?): > > # grep . /proc/sys/fs/prot* > /proc/sys/fs/protected_hardlinks:1 > /proc/sys/fs/protected_symlinks:1 > # cd ~psz > # ls -ld my* > drwx------ 2 psz amstaff 4096 Oct 14 18:46 mydir > lrwxrwxrwx 1 psz amstaff 5 Oct 14 18:46 mylink -> mydir > # chown mike mylink > # ls -ld my* > drwx------ 2 mike amstaff 4096 Oct 14 18:46 mydir > lrwxrwxrwx 1 psz amstaff 5 Oct 14 18:46 mylink -> mydir > # You are operating here outside of /tmp (sticky world-writable directory) which the above issue for the init scripts relies on, right? fs.protected_(hardlinks|symlinks) is exactly a hardening for those issues: https://www.kernel.org/doc/Documentation/sysctl/fs.txt https://sources.debian.net/src/linux/3.16.36-1%2Bdeb8u1/Documentation/sysctl/fs.txt/#L205 In the release notes such issues are not treated as security-issues anymore since: https://www.debian.org/releases/stable/amd64/release-notes/ch-whats-new.en.html#security > > So while I think it should be fixed, this would not warrant a DSA, > > since mitigated by default in Debian. > > No mitigation: fix and DSA, please! See my explanation above. I'm not saying the issue should not be fixed, if that was the impression from our replies, then this can be rectified; but it does not seem warrant a DSA (so can be fixed via a regular update via a point release). Maybe still I'm missing something, so if you have a PoC could you please share your PoC it with a...@debian.org and t...@security.debian.org? Regards, Salvatore __ This is the maintainer address of Debian's Java team <http://lists.alioth.debian.org/cgi-bin/mailman/listinfo/pkg-java-maintainers>. Please use debian-j...@lists.debian.org for discussions and questions.