Hi I have recently reported a vulnerability in Tomcat packages on Debian-based distros: http://legalhackers.com/advisories/Tomcat-DebPkgs-Root-Privilege-Escalation-Exploit-CVE-2016-1240.html It appears that Gentoo Tomcat packages have a similar vulnerability. For example the init script mentioned in: https://searchcode.com/codesearch/view/7600777/ does perform the same dangerous chown operation. You can send me the listing of /var/log/tomcat* directories as well as current tomcat init scripts if you want me to verify on the other tomcat versions. Please verify and let me know. Regards, Dawid Golunski http://legalhackers.com
Hello Dawid, thanks for the time for your report here. I saw your publication on oss-security and I asked to maintainer to check if we are affected. In the meantime he will give a better answer, our init script can be retrieved here: https://gitweb.gentoo.org/repo/gentoo.git/tree/www-servers/tomcat/files/tomcat-r1.init
Wow, I didn't know that "--no-dereference" was not the default behavior of chown. Our *current* init script looks safe.
Here's my post-coffee analysis: It's not obvious that our current fixed init script is sufficient, because the way tomcat works, various other init scripts get generated by tomcat-instance-manager.bash, and those are never updated. For example, if I run, tomcat-instance-manager.bash --suffix www.example.com then that script will generate a *copy* of the current tomcat init script, /etc/init.d/tomcat-7-www.example.com So, I was worried that maybe some people would be running copies of the old, vulnerable, init script. Fortunately it looks like the bash instance manager script was introduced around the same time as the fixed init script: https://sources.gentoo.org/cgi-bin/viewvc.cgi/gentoo-x86/www-servers/tomcat/files/tomcat.init?revision=1.1&view=markup https://sources.gentoo.org/cgi-bin/viewvc.cgi/gentoo-x86/www-servers/tomcat/files/tomcat-instance-manager.bash?revision=1.1&view=markup As a result, I think anyone with such a copy of the init script will not have a vulnerable one.
Introduced in tomcat-6 via https://sources.gentoo.org/cgi-bin/viewvc.cgi/gentoo-x86/www-servers/tomcat/files/6/tomcat.init?hideattic=0&r1=1.2&r2=1.3 With tomcat-7 our runscript was rewritten; First version with the new runscript was tomcat-7.0.5. Not sure if it is possible to run >=tomcat-7.0.5 with previous runscript version. If it is possible, we should create a GLSA to tell people to re-check their runscript (grep for chown should be enough). @ Maintainer(s): How do you handle tomcat runscript updates at the moment if users may have duplicated the runscript using the bash script?
(In reply to Thomas Deutschmann from comment #4) > > @ Maintainer(s): How do you handle tomcat runscript updates at the moment if > users may have duplicated the runscript using the bash script? In lieu of an answer from the Java team: I don't think they are handled. (That may be fixable if we installed tomcat.init and then symlinked it using the instance manager, kind of how we symlink our NIC scripts to net.lo.)
(In reply to Michael Orlitzky from comment #5) > In lieu of an answer from the Java team: I don't think they are handled. > > (That may be fixable if we installed tomcat.init and then symlinked it using > the instance manager, kind of how we symlink our NIC scripts to net.lo.) Right, but we need to tell existing users that they have to check their runscripts on their own because we cannot be sure if they ever copied one script and set a name we cannot detect in pkg_postinst. It should be sufficient to shown an ewarn in pkg_postinst only when REPLACING_VERSIONS isn't empty. @ Maintainer(s): Please tell us how you want to proceed here.
(In reply to Thomas Deutschmann from comment #6) > > Right, but we need to tell existing users that they have to check their > runscripts on their own because we cannot be sure if they ever copied one > script and set a name we cannot detect in pkg_postinst. > The init script copying may have been introduced with the instance manager that appeared at the same time as the fixed init script. I'm not sure, but before that, I think tomcat could only run one instance with a single portage-managed init script. If that's the case, updating to the newer tomcat (with the instance manager) would have uninstalled all of the vulnerable init scripts. Looking back through CVS, I think tomcat-6.0.35.ebuild is the last vulnerable version, and it had a single init script. The next revision tomcat-6.0.35-r1.ebuild introduces the instance manager, but also the fixed init script. (I'm not very good at reading the CVS web interface, so please verify that.)
we have only version 7.0.77 in the tree from this slot atm
there is some work at https://github.com/gentoo/gentoo/pull/1358 waiting to be reviewed and applied by someone. that should imo solve the issue for good. unfortunately i do not have time to review and test it due to real life priorities and so far nobody stepped up to take the task. anyway, imo it deserves attention.
So are you saying this version is affected?
(In reply to Yury German from comment #10) > So are you saying this version is affected? The potential issue is that the instance manager leaves old copies of the init script around, so even if we fix the init script, users may remain vulnerable. The work on https://github.com/gentoo/gentoo/pull/1358 would do away with the instance manager, preventing similar problems in the future. However, it has been a very long time since a vulnerable init script was in the tree. Users need only check their init scripts for the word "chown" to ensure that they are not affected. Current versions of the package still install a *copy* of the init script, but the installed copy is not vulnerable.
This issue was resolved and addressed in GLSA 201705-09 at https://security.gentoo.org/glsa/201705-09 by GLSA coordinator Yury German (BlueKnight).
