Hi Paul, hi Markus, On Fri, Oct 14, 2016 at 08:42:11AM +1100, paul.sz...@sydney.edu.au wrote: > Dear Markus, > > >> [ I contacted t...@security.debian.org about this, but no response ... ] > > ... Please send them to the security team > > first and not to a public mailing list. > > I did. They did not reply within what seemed a reasonable timeframe.
To be fair one could say, the initial mail was on 'Thu Oct 13 01:38:41 UTC 2016' and the bugreport on 'Thu Oct 13 20:22:50 UTC 2016'. But thanks for reporting (appreciated!) and it's maybe anyway better to have it tracked in the BTS in this case: > >> Recently DSA-3670 was released, and /etc/init.d/tomcat8 modified so... > > No, we did not modify this part in /etc/init.d/tomcat8. ... > > Whoops, sorry, you are right. Now checking, I do not see how I got > confused. This is a separate, maybe new issue. Yes, I think, that should be considered a different issue. Please not that in your attack vector, though 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?). So the attacker would need to do it two-staged, first a directory, which will pass the mkdir -p successfully, then replace the directory with a symlink which will be followed. 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. So while I think it should be fixed, this would not warrant a DSA, since mitigated by default in Debian. Regards, Salvatore