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"
ppc64 stable for tomcat-6.0.16
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.
