As reported by me on oss-security at $URL, tomcat:7, at least on gentoo, has a world-redable log/logdir: drwxr-xr-x 2 ago ago 4096 Feb 22 13:50 . drwxr-xr-x 8 root root 4096 Feb 22 13:50 .. -rw-r--r-- 1 ago ago 5919 Feb 22 13:51 catalina.2013-02-22.log -rw-r--r-- 1 ago ago 0 Feb 22 13:50 host-manager.2013-02-22.log -rw-r--r-- 1 ago ago 0 Feb 22 13:50 localhost.2013-02-22.log -rw-r--r-- 1 ago ago 0 Feb 22 13:50 localhost_access_log.2013-02-22.txt -rw-r--r-- 1 ago ago 0 Feb 22 13:50 manager.2013-02-22.log
CVE-2013-0346 (http://nvd.nist.gov/nvd.cfm?cvename=CVE-2013-0346): ** DISPUTED ** Apache Tomcat 7.x uses world-readable permissions for the log directory and its files, which might allow local users to obtain sensitive information by reading a file. NOTE: One Tomcat distributor has stated "The tomcat log directory does not contain any sensitive information."
Hi security We'd like to know what you expect from us here. As explained in the mailing list where Agostino asked for help, other web servers seem to be setting up their log directory in the same fashion i.e. allowing everybody to read the directory content [1] [2]. Also, it's worth nothing that Red Hat filed a bug upstream about this issue and Apache Tomcat devs don't consider it as a flaw [3]. Which leads me to question the veracity of this bug. [1] http://www.openwall.com/lists/oss-security/2013/02/22/16 [2] http://www.openwall.com/lists/oss-security/2013/02/22/18 [3] https://bugzilla.redhat.com/show_bug.cgi?id=924841#c3
The logs of a webserver should not be world-readable. I don't care what tomcat devs says about. If you want to fix it, is enough chmod 750 to the main directory of the tomcat logs.
One thing for sure: tomcat ebuilds do not create the "logs" directory. I have all 3 versions installed (6+7+8) and I was able to start tomcat only after creating the "logs" directory in $CATALINA_BASE. See: monsieurp@epsilon ~ $ sudo /usr/share/tomcat-8/bin/startup.sh Using CATALINA_BASE: /usr/share/tomcat-8 [...] touch: cannot touch ‘/usr/share/tomcat-8/logs/catalina.out’: No such file or directory /usr/share/tomcat-8/bin/catalina.sh: line 402: /usr/share/tomcat-8/logs/catalina.out: No such file or directory monsieurp@epsilon ~ $ sudo /usr/share/tomcat-7/bin/startup.sh Using CATALINA_BASE: /usr/share/tomcat-7 [...] touch: cannot touch ‘/usr/share/tomcat-7/logs/catalina.out’: No such file or directory /usr/share/tomcat-7/bin/catalina.sh: line 386: /usr/share/tomcat-7/logs/catalina.out: No such file or directory monsieurp@epsilon ~ $ sudo /usr/share/tomcat-6/bin/startup. Using CATALINA_BASE: /usr/share/tomcat-6 [...] touch: cannot touch ‘/usr/share/tomcat-6/logs/catalina.out’: No such file or directory /usr/share/tomcat-6/bin/catalina.sh: line 374: /usr/share/tomcat-6/logs/catalina.out: No such file or directory monsieurp@epsilon ~ $ sudo mkdir -p /usr/share/tomcat-{6,7,8}/logs Now let's try to start tomcat 7 for instance: monsieurp@epsilon ~ $ sudo /usr/share/tomcat-7/bin/startup.sh [...] Tomcat started. monsieurp@epsilon ~ $ ps aux | grep tomcat root 27088 106 2.0 2390216 82324 pts/7 Sl 15:36 0:04 /usr/lib/jvm//icedtea-7/bin/java [...] -Dcatalina.base=/usr/share/tomcat-7 -Dcatalina.home=/usr/share/tomcat-7 -Djava.io.tmpdir=/usr/share/tomcat-7/temp org.apache.catalina.startup.Bootstrap start @Ago: It's very likely that the directory perms you're seeing are those set up by your root's umask. Nonetheless, I agree, we should set up this directory ourselves to avoid more confusions.
+*tomcat-6.0.44-r0 (21 Jul 2015) +*tomcat-7.0.59-r2 (21 Jul 2015) +*tomcat-8.0.23-r2 (21 Jul 2015) + + 21 Jul 2015; Patrice Clement <monsieurp@gentoo.org> +tomcat-6.0.44-r0.ebuild, + +tomcat-7.0.59-r2.ebuild, +tomcat-8.0.23-r2.ebuild: + Create logs directory in $CATALINA_BASE and set up perms to 0750. Fix security + bug 458890. +
Failed to install fixed www-servers/tomcat-7.0.59-r2: fperms want absolute path (portage-2.2.20). Need change "fperms 0750 logs" to "fperms 0750 /logs"
tomcat-6.0.44-r0 tomcat-7.0.59-r2 tomcat-8.0.23-r2 Maintainer(s), please advise if you when you are ready for stabilization or call for stabilization yourself.
monsieurp → gentoo-x86 (www-servers/tomcat/) Feed dodir and fperms functions with the ${dest} variable. This variable is already formatted with the $CATALINA_BASE full path. Fix security bug 458890. There was also a problem when generating the javadoc that we picked up on just now. I'm posting it here but it's totally unrelated to this bug. monsieurp → gentoo-x86 (www-servers/tomcat/) Override java.7.home property unconditionally. This was causing tomcat's javadoc generation to fail.
Arch teams, Please stabilise: www-servers/tomcat-6.0.44-r0 www-servers/tomcat-7.0.59-r2 www-servers/tomcat-8.0.23-r2 (amd64+x86 only) Target arches: amd64 ppc ppc64 x86 Thanks.
amd64 stable
x86 stable
ping @ppc @ppc64
ppc stable
ppc64 stable. Maintainer(s), please cleanup. Security, please vote.
+ 04 Aug 2015; Patrice Clement <monsieurp@gentoo.org> -tomcat-6.0.44.ebuild, + -tomcat-7.0.59-r1.ebuild, -tomcat-7.0.59.ebuild, -tomcat-8.0.23-r1.ebuild, + -tomcat-8.0.23.ebuild: + Remove vulnerable versions. Fixes security bug 458890. + Clean up done.
GLSA Vote: No
ping @security. Can we move on?
GLSA vote: no.
