Gentoo Websites Logo
Go to: Gentoo Home Documentation Forums Lists Bugs Planet Store Wiki Get Gentoo!
Bug 595978 (CVE-2016-1240) - <www-servers/tomcat-7.0.5: root privilege escalation (CVE-2016-1240)
Summary: <www-servers/tomcat-7.0.5: root privilege escalation (CVE-2016-1240)
Status: RESOLVED FIXED
Alias: CVE-2016-1240
Product: Gentoo Security
Classification: Unclassified
Component: Vulnerabilities (show other bugs)
Hardware: All Linux
: Normal major (vote)
Assignee: Gentoo Security
URL: http://legalhackers.com/advisories/To...
Whiteboard: B1 [glsa cve]
Keywords:
Depends on:
Blocks:
 
Reported: 2016-10-02 20:57 UTC by Dawid Golunski
Modified: 2017-05-18 02:02 UTC (History)
2 users (show)

See Also:
Package list:
Runtime testing required: ---


Attachments

Note You need to log in before you can comment on or make changes to this bug.
Description Dawid Golunski 2016-10-02 20:57:48 UTC
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
Comment 1 Agostino Sarubbo gentoo-dev 2016-10-03 08:11:41 UTC
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
Comment 2 Michael Orlitzky gentoo-dev 2016-10-03 11:28:40 UTC
Wow, I didn't know that "--no-dereference" was not the default behavior of chown.

Our *current* init script looks safe.
Comment 3 Michael Orlitzky gentoo-dev 2016-10-03 14:38:51 UTC
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.
Comment 4 Thomas Deutschmann gentoo-dev Security 2016-12-05 19:05:30 UTC
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?
Comment 5 Michael Orlitzky gentoo-dev 2016-12-08 19:15:55 UTC
(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.)
Comment 6 Thomas Deutschmann gentoo-dev Security 2017-01-09 19:17:19 UTC
(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.
Comment 7 Michael Orlitzky gentoo-dev 2017-01-09 19:39:29 UTC
(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.)
Comment 8 Miroslav Šulc gentoo-dev 2017-05-09 14:28:21 UTC
we have only version 7.0.77 in the tree from this slot atm
Comment 9 Miroslav Šulc gentoo-dev 2017-05-09 17:29:07 UTC
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.
Comment 10 Yury German Gentoo Infrastructure gentoo-dev Security 2017-05-16 05:56:31 UTC
So are you saying this version is affected?
Comment 11 Michael Orlitzky gentoo-dev 2017-05-16 21:20:13 UTC
(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.
Comment 12 GLSAMaker/CVETool Bot gentoo-dev 2017-05-18 02:02:36 UTC
This issue was resolved and addressed in
 GLSA 201705-09 at https://security.gentoo.org/glsa/201705-09
by GLSA coordinator Yury German (BlueKnight).