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
School of Mathematics and Statistics   University of Sydney    Australia

This is the maintainer address of Debian's Java team
Please use for discussions and questions.

Reply via email to