Dear Markus, > First of all you can only gain write permissions as the tomcat8 user if > you exploit an yet unknown security vulnerability in a web application > or Tomcat itself. Debian's tomcat8 user has no shell access by default.
Yes, this is a privilege escalation issue: exactly as in DSA-3670. > So the server must be running ... No, you are wrong. Once I managed run-any-code-as-tomcat8 from the running server, I set up something to run in the background, to keep running after the server exited. > ... and somehow you managed to remove /tmp/tomcat8-tomcat8-tmp and > replaced the directory with a symlink to an arbitrary file. No I do not remove anything. You do the remove, I create the symlink after you removed (and before you attempt the mkdir). > Your attack vector requires that the server must be restarted. ... Yes, exactly as in DSA-3670. > ... But there is another rm -rf "$JVM_TMP" command in the stop target > that would remove your symlink again. No, not another rm. I create the symlink after your rm. > Ok, let's imagine that you could find a way around the rm -rf commands. > Let's remove those rm -rf "$JVM_TMP" calls in /etc/init.d/tomcat8. Then > run systemctl daemon-reload. Log in as tomcat8 user and create your > symlink for /tmp/tomcat8-tomcat8-tmp. If I run systemctl restart tomcat8 > now, I get this: > > Job for tomcat8.service failed because the control process exited with > error code. > > The symlink is still present and nothing has changed regarding the file > permissions for my arbitrary file. You created the wrong symlink: not to a random place and not to a file, but a symlink to /etc (an existing directory). Please try again. > I agree that we should improve the init script in this regard but I > actually don't see a major risk like a root escalation for users at the > moment and I suggest to lower the severity of this bug report to important. Do the right test, please. You will see /etc owned by tomcat8, that effectively gives root access. >> What response time should I have expected of team@security? You had >> close to a whole day... > In my opinion it is generally understood that you should give people at > least enough time to react to an e-mail and to assess the issue. > Expecting a response time in less than a day is not very reasonable, > especially when there are things like the time difference between > Australia and Europe. You can do better, if you try. Cheers, Paul Paul Szabo p...@maths.usyd.edu.au http://www.maths.usyd.edu.au/u/psz/ School of Mathematics and Statistics University of Sydney Australia __ 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.
