Bugzilla Bug 196066

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.

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.

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.

(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.

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 :)

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.

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.

(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.
:-)

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.

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.

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"

amd64 stable

x86 stable

ppc64 stable

ppc stable

C3 means a vote.

I tend to vote NO. But otoh we could combine it with #195571.

Looks like I need to patch again :( that one liner wasn't enough.

http://marc.info/?l=tomcat-dev&m=119293594808371&w=2

(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 :-)

(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?

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.

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.

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.

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"

x86 stable

ppc64 stable for tomcat-6.0.16

ppc stable

amd64 (finally) stable, last arch.

time for GLSA decision. I vote NO.

I vote YES, this is one bug of a set of bugs fixed, see bug 203169.

changing my vote, we'll combine it with bug #203169 and the request is already
drafted anyway.

GLSA 200804-10, sorry for the delay.