Yeah ok, I see how "apt update && apt upgrade" will strip your workaround from
the system.
Thanks for clarifying.
My analysis agrees to everything else.
Thanks for additionally pointing out the sourcing of /etc/default/tomcat7 and
most importantly the $POLICY_CACHE at
POLICY_CACHE="$CATALINA_BASE/policy/catalina.policy"
Thanks for making me dig even further in that case, I think I have
resolved the bits that introduced it now.
I had missed the latter which makes the fix less of a headache.
Let me fetch some other opinions upfront on "symlink to avoid users of working
/work/ path" vs "fix in the used path".
I was wondering when between tomcat7 and tomcat8 this was fixed at [1] only to
realize that it actually was a delta that introduced the bug.
That leads us to [2] and also the related bug 591802 and [3].
Those read pretty much like the bug here but vice versa.
I wonder if that tomcat6 fix just never made sense in the way it is on tomcat7.
Never the less people might have set things up in a way to make the
"$CATALINA_BASE"/work/catalina.policy" path work to get around the
issue.
It is worth to mention that in later versions this fx is still carried,
juts the paths changed, see [4].
It seems the pathing was changed from "work" to "policy" (but not back to the
upstream "conf") as part if this:
* CVE-2016-1240 follow-up:
- The previous init.d fix was vulnerable to a race condition that could
be exploited to make any existing file writable by the tomcat user.
Thanks to Paul Szabo for the report and the fix.
- The catalina.policy file generated on startup was affected by a
similar
vulnerability that could be exploited to overwrite any file on the
system.
Thanks to Paul Szabo for the report.
And that made me realize that it might actually have been introduced with the
last Xenial security patch. It has:
7 * SECURITY UPDATE: privilege escalation via insecure init script
8 - debian/tomcat7.init: don't follow symlinks when handling the
9 catalina.out file.
10 - CVE-2016-1240
That change can be seen in [5], but it has none of the follow ups I
referred in [4].
Tagging the bug as update regression and assigning Eduardo who worked on
the security update. Upgrade regression fixes are usually best with the
one who broke it anyway - to consider all other things that made the
first change necessary.
[1]: https://github.com/apache/tomcat70/blame/trunk/bin/catalina.sh
[2]:
https://git.launchpad.net/ubuntu/+source/tomcat7/tree/debian/patches/0009-Use-java.security.policy-file-in-catalina.sh.patch?h=ubuntu/xenial-devel
[3]: https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=585379
[4]:
https://git.launchpad.net/ubuntu/+source/tomcat8/tree/debian/patches/0009-Use-java.security.policy-file-in-catalina.sh.patch?h=ubuntu/bionic-devel
[5]:
https://git.launchpad.net/ubuntu/+source/tomcat7/diff/debian/tomcat7.init?h=ubuntu/xenial-devel
** Bug watch added: Debian Bug tracker #585379
https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=585379
** CVE added: https://cve.mitre.org/cgi-bin/cvename.cgi?name=2016-1240
** Tags added: regression-update
** Changed in: tomcat7 (Ubuntu Xenial)
Assignee: (unassigned) => Eduardo dos Santos Barretto (ebarretto)
** Changed in: tomcat7 (Ubuntu Trusty)
Assignee: (unassigned) => Eduardo dos Santos Barretto (ebarretto)
--
You received this bug notification because you are a member of Ubuntu
Bugs, which is subscribed to Ubuntu.
https://bugs.launchpad.net/bugs/1799990
Title:
tomcat7 doesn't start after upgrade to 7.0.68-1ubuntu0.3
To manage notifications about this bug go to:
https://bugs.launchpad.net/ubuntu/+source/tomcat7/+bug/1799990/+subscriptions
--
ubuntu-bugs mailing list
[email protected]
https://lists.ubuntu.com/mailman/listinfo/ubuntu-bugs
