> 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.
Paul Szabo p...@maths.usyd.edu.au http://www.maths.usyd.edu.au/u/psz/
School of Mathematics and Statistics University of Sydney Australia