Gentoo Websites Logo
Go to: Gentoo Home Documentation Forums Lists Bugs Planet Store Wiki Get Gentoo!
Bug 196066 (CVE-2007-5461) - www-servers/tomcat Remote File Disclosure (CVE-2007-5461)
Summary: www-servers/tomcat Remote File Disclosure (CVE-2007-5461)
Status: RESOLVED FIXED
Alias: CVE-2007-5461
Product: Gentoo Security
Classification: Unclassified
Component: Vulnerabilities (show other bugs)
Hardware: All Linux
: High minor (vote)
Assignee: Gentoo Security
URL: http://thread.gmane.org/gmane.comp.ja...
Whiteboard: C3 [glsa]
Keywords: InVCS
Depends on: CVE-2007-5333
Blocks:
  Show dependency tree
 
Reported: 2007-10-16 16:09 UTC by Tobias Heinlein (RETIRED)
Modified: 2008-04-10 20:56 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 Tobias Heinlein (RETIRED) gentoo-dev 2007-10-16 16:09:21 UTC
CVE-2007-5461 (http://nvd.nist.gov/nvd.cfm?cvename=CVE-2007-5461):
  Absolute path traversal vulnerability in Apache Tomcat, under certain
  configurations, allows remote authenticated users to read arbitrary files via
  a WebDAV write request that specifies an entity with a SYSTEM tag.
Comment 1 Tobias Heinlein (RETIRED) gentoo-dev 2007-10-16 16:13:25 UTC
Maintainers, please advise.
A patch is included in the URL, it's up to you whether to patch our ebuild or to wait for upstream action.
Comment 2 William L. Thomson Jr. (RETIRED) gentoo-dev 2007-10-16 16:31:22 UTC
Nothing to be done here. Note in the link above it states clearly

"The Tomcat security team has evaluated this vulnerability and
determined that default installations of Tomcat 6.0.x, 5.5.x and 4.1.x
and not affected.

In order to be affected systems must have:
- one or more contexts configured for webdav using Tomcat's built-in
webdav implementation
- enabled write capability via webdav"

So a user would have to enable this feature or etc. I would assume in the process they would look out for any issues like security vulnerabilities. I haven't used webdav myself, but seem to recall it have lots of exploits in the past. Mostly when used with Apache, so not to surprised about issues with webdav and Tomcat.

We could advise on this, but it's only going to effect those who have enabled webdav. Just as upstream, we don't enable that by default. Seems 5.5.x does have it enabled by default, but is read-only. So can't be exploited per the vulnerability.

Pretty sure we are in the clear and no action is needed on our behalf. I really don't think this merits a GSLA. Or possible even keeping bug open. But I will leave for others to close.
Comment 3 Petteri Räty (RETIRED) gentoo-dev 2007-10-16 16:34:57 UTC
(In reply to comment #2)
> 
> Pretty sure we are in the clear and no action is needed on our behalf. I really
> don't think this merits a GSLA. Or possible even keeping bug open. But I will
> leave for others to close.
> 

I don't see anything wrong with patching it as there is an upstream approved patch for it. If you know that the next version is just around the corner, then it probably doesn't make sense.
Comment 4 William L. Thomson Jr. (RETIRED) gentoo-dev 2007-10-16 16:39:30 UTC
Although depending on how others feel. I am open to applying said patch and protecting user who might enable webdav. If others feel that's the best course of action. Otherwise likely will just wait for the next upstream release. Doubt this is major enough to motivate a new release. Thus wanted to mention I am open to apply the patch in the mean time. Or we could leave patching up to users, as punishment for using webdav :)
Comment 5 Robert Buchholz (RETIRED) gentoo-dev 2007-10-16 17:05:36 UTC
I don't think having WebDAV write-enabled is either stupid or a configuration we do not support. Please note that the discussion right now is not whether a GLSA should be issued, but whether this vulnerability should be fixed. As Petteri pointed out, upstream advised its users to protect themselves.

There are stupid configurations, or configurations that make very clear that they possibly open up security holes, but besides that, we should support non-default configs, too. So please include the patch in a revbump or in a version bump in the near future.
Comment 6 William L. Thomson Jr. (RETIRED) gentoo-dev 2007-10-16 17:24:36 UTC
Well the lack of official documentation from Tomcat is not helping me research this matter. Further more looking at the actual CVE

http://nvd.nist.gov/nvd.cfm?cvename=CVE-2007-5461

Access Vector:  Network exploitable
Access Complexity: Medium
Authentication: Required to exploit
Impact Type: Allows unauthorized disclosure of information

So they would have to authenticate to exploit. Any exploit or etc would be internal. Which I am trying to research how one would even use webdav. Seems like it would be enabled for internal usage maybe over a lan or etc. This does not seem to be an exploit someone from the outside world could easily abuse. Or one without authentication.

Looks to also still be a candidate
http://cve.mitre.org/cgi-bin/cvename.cgi?name=CVE-2007-5461

It's clear the exploit requires authentication
http://www.milw0rm.com/exploits/4530

I just don't see this feature in wide use on Gentoo. If at all. Much less it's an internal exploit that only an authenticated user could exploit. Which implies they are already trusted to an extent.

I am not disputing the issue. Just the level of severity of it being exploited on Gentoo, and how quickly I need to react if at all. Do really want to subject all users to updating, having a stable and unstable version of Tomcat and etc? All around a feature, that might be used. With an exploit that can only come from within. Just not much to motivate me to act.

For now till it's status changes to an official "Entry" status on the CVE list, I will hold off on any action.
Comment 7 Robert Buchholz (RETIRED) gentoo-dev 2007-10-16 18:00:09 UTC
(In reply to comment #6)
> I am not disputing the issue. Just the level of severity of it being exploited
> on Gentoo, and how quickly I need to react if at all.

I'm not saying this is a major bug, I follow your argument. That's why it's C3 (second-lowest of all 12 ratings) and the bug is "minor". It still is a bug with security impact, though. Target delay for C3 is 20 days (including stabling), so you can walk your dog and go out for a drink before fixing this.
It would be nice if you did fix it within the target time, though.

> Do really want to subject
> all users to updating, having a stable and unstable version of Tomcat and etc?
> All around a feature, that might be used. With an exploit that can only come
> from within. Just not much to motivate me to act.

I don't see a way to issue a new stable only for those using this feature.


> For now till it's status changes to an official "Entry" status on the CVE list,
> I will hold off on any action.

The latest "entry" is CVE-2004-0356, they have quite a backlog. If you wait till that happens, a new release and stabling will include a patch for this. :-)
Comment 8 William L. Thomson Jr. (RETIRED) gentoo-dev 2007-10-16 18:16:50 UTC
Ok, let me take a newb stance. If I do patch this and etc. Will we then be looking to rush stabilize it, to address the security issue? That seems like the logical steps if we are acting on a security issue no?

Likely will just go ahead and just patch to make all happy and move on with this. Just sucks, because Tomcat 5.5.25 was just stabilized. So will have to get others involved there again. Was just hoping to limit extra work for all, unless it was absolutely necessary.
Comment 9 William L. Thomson Jr. (RETIRED) gentoo-dev 2007-10-16 21:21:14 UTC
patched both 5.5.25 and 6.0.14, -r1 versions. Had to remake patch, since paths were a bit different in 6.0.x. Also not sure if we need to go ahead and request stabilization of both versions. Seems like the next logical step since this is  a security issue.
Comment 10 Robert Buchholz (RETIRED) gentoo-dev 2007-10-16 23:34:43 UTC
Thanks for patching and your advice. The arch teams are always eager to test and mark stable new ebuilds. We only try to feed their needs as best as we can.

So, please test and mark stable new versions of www-servers/tomcat:
* 5.5.25-r1 for "amd64 x86"
* 6.0.14-r1 for "amd64 ppc ppc64 x86"
Comment 11 William L. Thomson Jr. (RETIRED) gentoo-dev 2007-10-17 02:08:41 UTC
amd64 stable
Comment 12 Christian Faulhammer (RETIRED) gentoo-dev 2007-10-17 06:23:21 UTC
x86 stable
Comment 13 Markus Rothe (RETIRED) gentoo-dev 2007-10-17 18:14:10 UTC
ppc64 stable
Comment 14 Tobias Scherbaum (RETIRED) gentoo-dev 2007-10-18 17:01:18 UTC
ppc stable
Comment 15 Robert Buchholz (RETIRED) gentoo-dev 2007-10-18 19:24:00 UTC
C3 means a vote.
Comment 16 Sune Kloppenborg Jeppesen gentoo-dev 2007-10-18 20:29:04 UTC
I tend to vote NO. But otoh we could combine it with #195571.
Comment 17 William L. Thomson Jr. (RETIRED) gentoo-dev 2007-10-21 03:16:57 UTC
Looks like I need to patch again :( that one liner wasn't enough.

http://marc.info/?l=tomcat-dev&m=119293594808371&w=2
Comment 18 Robert Buchholz (RETIRED) gentoo-dev 2007-10-21 10:18:08 UTC
(In reply to comment #17)
> Looks like I need to patch again :( that one liner wasn't enough.

You just gained another 10 points in patching experience count :-)
Comment 19 Robert Buchholz (RETIRED) gentoo-dev 2007-10-29 22:32:42 UTC
(In reply to comment #17)
> Looks like I need to patch again :( that one liner wasn't enough.
> 
> http://marc.info/?l=tomcat-dev&m=119293594808371&w=2

Anything holding this back?
Comment 20 William L. Thomson Jr. (RETIRED) gentoo-dev 2007-11-16 19:40:47 UTC
Since upstream provided two solutions, not sure which was committed, need to check. I held off till they decided one way or another. Which likely has occurred by now, just need to go digging in svn or etc. However there is about to be a new 6.0.x release. So I will likely just wait for that there. As for 5.5.x I will address that likely around the time I go to bump 6.0.x to latest release. 

If it was more pressing I would move faster, but I kinda consider the exploit an internal attack. And low priority. Not to mention having already made one attempt to fix via a patch.
Comment 21 William L. Thomson Jr. (RETIRED) gentoo-dev 2008-02-05 18:49:20 UTC
Just committed 5.5.26, 6.0.16 should be released soon. Upstream has voted, just waiting on actual release to take place. I will comment again when 6.0.16 hits tree which will resolve this bug. At least from my side, not sure if security wants to GSLA this, etc.
Comment 22 William L. Thomson Jr. (RETIRED) gentoo-dev 2008-02-07 17:28:38 UTC
6.0.16 was just committed to tree. So we are good to go. Adding InCVS keyword, since we are fixed now in CVS. Not sure if we should consider expedited stabilization. There really were no changes to either ebuild. Very minor to 6.0.16, and biggest change for 5.5.25 was I had to remake a patch for the build system.

But either way, don't consider this a major exploit or vulnerability. Security do with it from where what ever you feel is best :) Good to go from my end.
Comment 23 Sune Kloppenborg Jeppesen gentoo-dev 2008-02-10 14:15:41 UTC
Thx William.

Arches please test and mark stable. Target keywoards are:

tomcat-5.5.26.ebuild:KEYWORDS="amd64 -ppc -ppc64 x86 ~x86-fbsd"
tomcat-6.0.16.ebuild:KEYWORDS="amd64 ppc ppc64 x86 ~x86-fbsd"
Comment 24 Markus Meier gentoo-dev 2008-02-10 15:45:06 UTC
x86 stable
Comment 25 Brent Baude (RETIRED) gentoo-dev 2008-02-11 02:59:03 UTC
ppc64 stable for tomcat-6.0.16
Comment 26 Tobias Scherbaum (RETIRED) gentoo-dev 2008-02-22 13:58:33 UTC
ppc stable
Comment 27 Markus Meier gentoo-dev 2008-03-17 22:36:23 UTC
amd64 (finally) stable, last arch.
Comment 28 Pierre-Yves Rofes (RETIRED) gentoo-dev 2008-03-18 09:12:19 UTC
time for GLSA decision. I vote NO.
Comment 29 Robert Buchholz (RETIRED) gentoo-dev 2008-03-21 02:26:57 UTC
I vote YES, this is one bug of a set of bugs fixed, see bug 203169.
Comment 30 Pierre-Yves Rofes (RETIRED) gentoo-dev 2008-04-04 15:09:11 UTC
changing my vote, we'll combine it with bug #203169 and the request is already drafted anyway.
Comment 31 Pierre-Yves Rofes (RETIRED) gentoo-dev 2008-04-10 20:56:22 UTC
GLSA 200804-10, sorry for the delay.