[SECURITY] Apache Tomcat 4.x JSP source disclosure vulnerability;Apache Tomcat 4.0.6 released
A security vulnerability has been confirmed to exist in Apache Tomcat 4.0.x releases (including Tomcat 4.0.5), which allows to use a specially crafted URL to return the unprocessed source of a JSP page, or, under special circumstances, a static resource which would otherwise have been protected by security constraint, without the need for being properly authenticated. This is based on a variant of the exploit that was disclosed on 09/24/2002. The cause - Using the invoker servlet in conjunction with the default servlet (responsible for handling static content in Tomcat) triggers this vulnerability. Who is vulnerable - - All Tomcat 4.0.x releases, except those in which the invoker servlet is disabled (this is not the default setting). - All Tomcat 4.1.x releases before 4.1.12, except those in which the invoker servlet is disabled (this is not the default setting), as well as 4.1.12 if and only if the invoker servlet has been enabled. The default Tomcat 4.1.12 installation is not vulnerable. Fixes and workarounds - Doing either of the following will resolve the security problem: A) Disabling the invoker servlet In the $CATALINA_HOME/conf/web.xml file (on Windows, %CATALINA_HOME%\conf\web.xml), comment out or remove the following XML fragment: servlet-mapping servlet-nameinvoker/servlet-name url-pattern/servlet/*/url-pattern /servlet-mapping B) If running any Tomcat 4.0.x releases, download and install the following binary patch: http://jakarta.apache.org/builds/jakarta-tomcat-4.0/release/v4.0.5/bin/hotfix/13365.zip Simply unzip the archive in the $CATALINA_HOME folder (on Windows %CATALINA_HOME%). Make sure paths are preserved when unzipping. The patch will overwrite the default webapp configuration file ($CATALINA_HOME/conf/web.xml) to add a workaround to protect against the security vulnerability. C) If running Tomcat 4.1.12 and the invoker servlet was enabled, it must be disabled at this time. A new Tomcat 4.1.x release incorporating the fix to the invoker servlet will be made available shortly. D) If running any Tomcat 4.0.x release, download and install Tomcat 4.0.6. New release --- The Apache Tomcat Team announces the immediate availability of a new release which includes a fix to the invoker servlet. Apache Tomcat 4.0.6: http://jakarta.apache.org/builds/jakarta-tomcat-4.0/release/v4.0.6/ Remy -- To unsubscribe, e-mail: mailto:[EMAIL PROTECTED] For additional commands, e-mail: mailto:[EMAIL PROTECTED]
Re: [OT] Re: [SECURITY] Apache Tomcat 4.x JSP source disclosure vulnerability
Bojan Smojver wrote: Quoting Bill Barker [EMAIL PROTECTED]: I'm agreeing with Costin. Please move this discussion to [EMAIL PROTECTED] It is off-topic here. Promise not to write a single byte on this topic on Tomcat-Dev list after this e-mail. Please don't missunderstand this - I have nothing against velocity, it is a nice tool ( I like the introspection/bean EL - I hope the jsp el will be close and I'm following the developments in commons ). There are many cases where its simplicity is a benefit, and for standalone use jsp can't be used. The problem is - this list is for servlet and jsp development. And I personally don't like the idea of treating the users ( web developers or not ) as stupid that shouln't have powerfull tools because they may do bad things. If you feel a need to convert people to velocity - I sugest you subscribe to Perl and PHP mailing lists ( and maybe ASP ? ). Maybe they'll apreciate this kind of arguments :-) Costin Bojan - This mail sent through IMP: http://horde.org/imp/ -- Costin -- To unsubscribe, e-mail: mailto:[EMAIL PROTECTED] For additional commands, e-mail: mailto:[EMAIL PROTECTED]
Re: Velocity (was RE: [SECURITY] Apache Tomcat 4.x JSP source disclosure vulnerability)
Bojan,
Just move the code you wrote into a context object, reference it and
poof! Velocity gets OutOfMemory, too. Bad code is limited to front ends.
Velocity is nice. It is an excellent project, and Geir is possibly the
most responsive and helpful project leader I have ever encountered.
But there IS programming in a Velocity page--it's just in Yet Another
Templating Language, one that both your developers and your web
designers have to learn. That creates opportunities for confusion.
(Especially where velocimacros are involved.)
-Original Message-
From: Bojan Smojver [mailto:[EMAIL PROTECTED]]
Sent: Wednesday, September 25, 2002 10:34 PM
To: Tomcat Developers List
Subject: Re: [SECURITY] Apache Tomcat 4.x JSP source
disclosure vulnerability
Not if:
runtime.interpolate.string.literals = false
Bojan
Quoting Tim Funk [EMAIL PROTECTED]:
That's what code reviews are for and in absence of that -
firing your
developers.
Wouldn't I also get an out of memory with this in Velocity?
#set($oom =
)
#foreach( $i in [-2147483648..2147483648] ) #set($oom =
$oom$oom$oom$oom$oom$oom$oom$oom$oom$oom$oom$oom$oom$oom ) #end
Bad code can kill ANY system for the determined(disgruntled)
developer.
Bojan Smojver wrote:
All right then, let's talk about JSP's. If I host my
clients' JSP's
on my
server
and a web designer puts this in (BTW, he wasn't forced, he simply
decided
he
wanted to do it):
---
Hashtable strings = new Hashtable();
int i=0;
while (true)
{
strings.put (dead+i, new StringBuffer(99));
}
---
--
To unsubscribe, e-mail: mailto:[EMAIL PROTECTED]
For additional commands, e-mail: mailto:[EMAIL PROTECTED]
RE: [SECURITY] Apache Tomcat 4.x JSP source disclosure vulnerability
Don't buy all the velocity hype.. It is not as great as they make it out to be. Please no flames from the velocity disiples as I will not respond. -Original Message- From: Bojan Smojver [mailto:[EMAIL PROTECTED]] Sent: Tuesday, September 24, 2002 6:23 PM To: Tomcat Dev List Subject: Re: [SECURITY] Apache Tomcat 4.x JSP source disclosure vulnerability On Wed, 2002-09-25 at 07:31, Matt Fury wrote: What's easier though? Upgrading a Tomcat server with a patch or re-architecting your whole site to accomodate for Velocity?? Short term, upgrading Tomcat. Long term, doing it in Velocity. Bojan -- To unsubscribe, e-mail: mailto:tomcat-dev- [EMAIL PROTECTED] For additional commands, e-mail: mailto:[EMAIL PROTECTED] -- To unsubscribe, e-mail: mailto:[EMAIL PROTECTED] For additional commands, e-mail: mailto:[EMAIL PROTECTED]
Re: [SECURITY] Apache Tomcat 4.x JSP source disclosure vulnerability
Yes I agree that some sort of JSP Tagging can be
beneficial but at times it is overkill. I think the
ultimate solution would be a combination of both.
--- Bojan Smojver [EMAIL PROTECTED] wrote:
On Wed, 2002-09-25 at 07:31, Matt Fury wrote:
What's easier though? Upgrading a Tomcat server
with a
patch or re-architecting your whole site to
accomodate
for Velocity??
Short term, upgrading Tomcat. Long term, doing it in
Velocity.
Bojan
--
To unsubscribe, e-mail:
mailto:[EMAIL PROTECTED]
For additional commands, e-mail:
mailto:[EMAIL PROTECTED]
=
int myName() {
cout -Matt Fury \n;
return 0;
}
__
Do you Yahoo!?
New DSL Internet Access from SBC Yahoo!
http://sbc.yahoo.com
--
To unsubscribe, e-mail: mailto:[EMAIL PROTECTED]
For additional commands, e-mail: mailto:[EMAIL PROTECTED]
Re: [SECURITY] Apache Tomcat 4.x JSP source disclosure vulnerability
Jon Scott Stevens wrote: Unlike JSP, we don't store (or encourage people to store) .vm files in the webroot. They can be anywhere on the fileystem and with custom resource loaders could even be stored in a database on another machine somewhere. Well, this is not a very good policy IMO. Self-contained applications are a good thing ( IMO ). And of course, JSPs don't have to be stored in the webroot either - and in general shouldn't be there except for development. It's better (IMO) to just precompile and include only the generated servlets - at least for a category of webapps. -- Costin -- To unsubscribe, e-mail: mailto:[EMAIL PROTECTED] For additional commands, e-mail: mailto:[EMAIL PROTECTED]
RE: [SECURITY] Apache Tomcat 4.x JSP source disclosure vulnerability
On Wed, 2002-09-25 at 20:59, John Trollinger wrote: Don't buy all the velocity hype.. It is not as great as they make it out to be. What hype? I don't follow here... Velocity is just a template language, plain, simple and relatively small. It's greatness comes from the fact that you cannot do things in it, not from that fact that you can. Other template languages might be as good or better, wouldn't know, but given that Velocity is a Jakarta project, it seemed like a reasonable suggestion to me. And it certainly does the job for me. I don't see why would sharing a good experience with someone qualify as hype. But all that is actually beside the point. The point is that you don't want your web designers to touch Java code, ever. Making web pages programs, with access into depths of you JVM, is what the initial problem with JSP's actually is. Please no flames from the velocity disiples as I will not respond. Why do you think anyone from Velocity crowd would flame you? I found most users and developers to be helpful and constructive. They certainly helped me switch from JSP's in no time at all. Bojan -- To unsubscribe, e-mail: mailto:[EMAIL PROTECTED] For additional commands, e-mail: mailto:[EMAIL PROTECTED]
RE: [SECURITY] Apache Tomcat 4.x JSP source disclosure vulnerability
Bojan Smojver wrote: On Wed, 2002-09-25 at 20:59, John Trollinger wrote: Don't buy all the velocity hype.. It is not as great as they make it out to be. What hype? I don't follow here... Velocity is just a template language, plain, simple and relatively small. It's greatness comes from the fact that you cannot do things in ... And Velocity does have a mailing list where all this can be discussed. This is tomcat-dev - for servlet and jsp development. If you have any ideas on how to improve jasper - great, but please don't waste our time with off topic subjects. Comments and sugestions on JSP spec can be addressed to the feedback address from Sun, we just implement it. ( and BTW, nobody forces you to use any java inside the JSP if you don't want to, or any of the features that are specific to jsps. ) Costin ( who enjoys writing java inside jsps, and thinks web applications _are_ programs, regardless of what other people claim ). it, not from that fact that you can. Other template languages might be as good or better, wouldn't know, but given that Velocity is a Jakarta project, it seemed like a reasonable suggestion to me. And it certainly does the job for me. I don't see why would sharing a good experience with someone qualify as hype. But all that is actually beside the point. The point is that you don't want your web designers to touch Java code, ever. Making web pages programs, with access into depths of you JVM, is what the initial problem with JSP's actually is. Please no flames from the velocity disiples as I will not respond. Why do you think anyone from Velocity crowd would flame you? I found most users and developers to be helpful and constructive. They certainly helped me switch from JSP's in no time at all. Bojan -- To unsubscribe, e-mail: mailto:[EMAIL PROTECTED] For additional commands, e-mail: mailto:[EMAIL PROTECTED]
RE: [SECURITY] Apache Tomcat 4.x JSP source disclosure vulnerability
Quoting Costin Manolache [EMAIL PROTECTED]:
And Velocity does have a mailing list where all this can be discussed.
This is tomcat-dev - for servlet and jsp development.
If you have any ideas on how to improve jasper - great, but please don't
waste our time with off topic subjects. Comments and sugestions on JSP spec
can be addressed to the feedback address from Sun, we just implement it.
( and BTW, nobody forces you to use any java inside the JSP if you don't
want to, or any of the features that are specific to jsps. )
All right then, let's talk about JSP's. If I host my clients' JSP's on my server
and a web designer puts this in (BTW, he wasn't forced, he simply decided he
wanted to do it):
---
Hashtable strings = new Hashtable();
int i=0;
while (true)
{
strings.put (dead+i, new StringBuffer(99));
}
---
What would happen to my Tomcat? I think this is called OutOfMemoryError and it
would affect every single web application running in that instance of Tomcat,
possibly owned by some other clients of mine. Completely unacceptable...
Web applications are collection programs and other stuff, for instance web
pages. However, web pages should not be programs because they are (usually)
maintained by non-programmers. The fact that you know what you're doing doesn't
exuse the shortcomings of the technology.
Bojan
-
This mail sent through IMP: http://horde.org/imp/
--
To unsubscribe, e-mail: mailto:[EMAIL PROTECTED]
For additional commands, e-mail: mailto:[EMAIL PROTECTED]
Re: [SECURITY] Apache Tomcat 4.x JSP source disclosure vulnerability
That's what code reviews are for and in absence of that - firing your
developers.
Wouldn't I also get an out of memory with this in Velocity?
#set($oom = )
#foreach( $i in [-2147483648..2147483648] )
#set($oom = $oom$oom$oom$oom$oom$oom$oom$oom$oom$oom$oom$oom$oom$oom )
#end
Bad code can kill ANY system for the determined(disgruntled) developer.
Bojan Smojver wrote:
All right then, let's talk about JSP's. If I host my clients' JSP's on my server
and a web designer puts this in (BTW, he wasn't forced, he simply decided he
wanted to do it):
---
Hashtable strings = new Hashtable();
int i=0;
while (true)
{
strings.put (dead+i, new StringBuffer(99));
}
---
--
To unsubscribe, e-mail: mailto:[EMAIL PROTECTED]
For additional commands, e-mail: mailto:[EMAIL PROTECTED]
Re: [SECURITY] Apache Tomcat 4.x JSP source disclosure vulnerability
Not if:
runtime.interpolate.string.literals = false
Bojan
Quoting Tim Funk [EMAIL PROTECTED]:
That's what code reviews are for and in absence of that - firing your
developers.
Wouldn't I also get an out of memory with this in Velocity?
#set($oom = )
#foreach( $i in [-2147483648..2147483648] )
#set($oom = $oom$oom$oom$oom$oom$oom$oom$oom$oom$oom$oom$oom$oom$oom )
#end
Bad code can kill ANY system for the determined(disgruntled) developer.
Bojan Smojver wrote:
All right then, let's talk about JSP's. If I host my clients' JSP's on my
server
and a web designer puts this in (BTW, he wasn't forced, he simply decided
he
wanted to do it):
---
Hashtable strings = new Hashtable();
int i=0;
while (true)
{
strings.put (dead+i, new StringBuffer(99));
}
---
--
To unsubscribe, e-mail: mailto:[EMAIL PROTECTED]
For additional commands, e-mail: mailto:[EMAIL PROTECTED]
-
This mail sent through IMP: http://horde.org/imp/
--
To unsubscribe, e-mail: mailto:[EMAIL PROTECTED]
For additional commands, e-mail: mailto:[EMAIL PROTECTED]
RE: [SECURITY] Apache Tomcat 4.x JSP source disclosure vulnerability
Bojan Smojver wrote: All right then, let's talk about JSP's. If I host my clients' JSP's on my server and a web designer puts this in (BTW, he wasn't forced, he simply decided he wanted to do it): And your proposed solution is ... ? Do you have a patch to solve this problem ? If so, send the code. IF not - please let me know what's your point here ? Do you think we're stupid and never heard about denial of service ? BTW, velocity _is_ a programming language - at least by the book definition, AFAIK it is turing complete. Some things are more difficult to do, but not impossible - you can see it as a benefit, I see it as a major lack of flexibility. So if you want to discuss solutions for this problem - I'm sure it'll help other templating and programming tools as well, including velocity ( which BTW can be a nice tool - and the lack of flexibility can be good in some cases ). I don't know what to do about your web designer - who doesn't know programming but decides to write some DOS code in his page. But I know that the best web applications I've used so far ( including some in php or perl ) were written by people who know a lot of programming. You need software engineers, useability engineers - not web designers who are clueless on programming ( and can't be trusted to not write DOS just for fun ). Costin -- To unsubscribe, e-mail: mailto:[EMAIL PROTECTED] For additional commands, e-mail: mailto:[EMAIL PROTECTED]
[OT] Re: [SECURITY] Apache Tomcat 4.x JSP source disclosure vulnerability
I'm agreeing with Costin. Please move this discussion to
[EMAIL PROTECTED] It is off-topic here.
- Original Message -
From: Bojan Smojver [EMAIL PROTECTED]
To: Tomcat Developers List [EMAIL PROTECTED]
Sent: Wednesday, September 25, 2002 7:33 PM
Subject: Re: [SECURITY] Apache Tomcat 4.x JSP source disclosure
vulnerability
Not if:
runtime.interpolate.string.literals = false
Bojan
Quoting Tim Funk [EMAIL PROTECTED]:
That's what code reviews are for and in absence of that - firing your
developers.
Wouldn't I also get an out of memory with this in Velocity?
#set($oom = )
#foreach( $i in [-2147483648..2147483648] )
#set($oom = $oom$oom$oom$oom$oom$oom$oom$oom$oom$oom$oom$oom$oom$oom )
#end
Bad code can kill ANY system for the determined(disgruntled) developer.
Bojan Smojver wrote:
All right then, let's talk about JSP's. If I host my clients' JSP's on
my
server
and a web designer puts this in (BTW, he wasn't forced, he simply
decided
he
wanted to do it):
---
Hashtable strings = new Hashtable();
int i=0;
while (true)
{
strings.put (dead+i, new StringBuffer(99));
}
---
--
To unsubscribe, e-mail:
mailto:[EMAIL PROTECTED]
For additional commands, e-mail:
mailto:[EMAIL PROTECTED]
-
This mail sent through IMP: http://horde.org/imp/
--
To unsubscribe, e-mail:
mailto:[EMAIL PROTECTED]
For additional commands, e-mail:
mailto:[EMAIL PROTECTED]
--
To unsubscribe, e-mail: mailto:[EMAIL PROTECTED]
For additional commands, e-mail: mailto:[EMAIL PROTECTED]
RE: [SECURITY] Apache Tomcat 4.x JSP source disclosure vulnerability
Quoting Costin Manolache [EMAIL PROTECTED]: Bojan Smojver wrote: All right then, let's talk about JSP's. If I host my clients' JSP's on my server and a web designer puts this in (BTW, he wasn't forced, he simply decided he wanted to do it): And your proposed solution is ... ? Don't use JSP's. I think that was very clear from the beginning of this thread. Do you have a patch to solve this problem ? If so, send the code. IF not - please let me know what's your point here ? Do you think we're stupid and never heard about denial of service ? No, I don't think that anyone here is stupid - how did you get that idea? And I don't have a patch. I don't think anyone has. Furthermore, since this is not my itch any more, why would I scratch? Also I don't think that malicious people can be prevented from causing problems if they really want to. But, if you make it easy for it to happen by accident to the people that don't really understand what they're doing, that's asking for trouble (e.g. how many web designer really understand the concept of session beans?). My point is this - JSP makes it dead easy to not write MVC applications and to fiddle with Java code where you shouldn't. Jon explained it here: http://jakarta.apache.org/velocity/ymtd/ymtd.html. Bottom line: let designers design and let programmers program. BTW, velocity _is_ a programming language - at least by the book definition, AFAIK it is turing complete. Some things are more difficult to do, but not impossible - you can see it as a benefit, I see it as a major lack of flexibility. Actually, I think even Velocity can do too much. An even better template language (or whatever you want to name it - don't really care) wouldn't allow method calls etc. But that's a different story altogether... So if you want to discuss solutions for this problem - I'm sure it'll help other templating and programming tools as well, including velocity ( which BTW can be a nice tool - and the lack of flexibility can be good in some cases ). I don't know what to do about your web designer - who doesn't know programming but decides to write some DOS code in his page. But I know that the best web applications I've used so far ( including some in php or perl ) were written by people who know a lot of programming. You need software engineers, useability engineers - not web designers who are clueless on programming ( and can't be trusted to not write DOS just for fun ). I'm not talking about my web designer, I'm talking about my clients' web designers. I cannot fire my clients' employees. I also don't have any influence over what they do and don't know, how qualified they are and if they care. Again, the point is - why give people power (that they don't need anyway) and hope nothing bad will happen? Bojan - This mail sent through IMP: http://horde.org/imp/ -- To unsubscribe, e-mail: mailto:[EMAIL PROTECTED] For additional commands, e-mail: mailto:[EMAIL PROTECTED]
Re: [OT] Re: [SECURITY] Apache Tomcat 4.x JSP source disclosure vulnerability
Quoting Bill Barker [EMAIL PROTECTED]: I'm agreeing with Costin. Please move this discussion to [EMAIL PROTECTED] It is off-topic here. Promise not to write a single byte on this topic on Tomcat-Dev list after this e-mail. Bojan - This mail sent through IMP: http://horde.org/imp/ -- To unsubscribe, e-mail: mailto:[EMAIL PROTECTED] For additional commands, e-mail: mailto:[EMAIL PROTECTED]
[SECURITY] Apache Tomcat 4.x JSP source disclosure vulnerability
A security vulnerability has been confirmed to exist in all Apache Tomcat 4.x releases (including Tomcat 4.0.4 and Tomcat 4.1.10), which allows to use a specially crafted URL to return the unprocessed source of a JSP page, or, under special circumstances, a static resource which would otherwise have been protected by security constraint, without the need for being properly authenticated. The cause - Using the invoker servlet in conjunction with the default servlet (responsible for handling static content in Tomcat) triggers this vulnerability. This particular configuration is available in the default Tomcat configuration. Workarounds --- An easy workaround exists for existing Tomcat installations, by disabling the invoker servlet in the default webapp configuration. In the $CATALINA_HOME/conf/web.xml file (on Windows, %CATALINA_HOME%\conf\web.xml), comment out or remove the following XML fragment: servlet-mapping servlet-nameinvoker/servlet-name url-pattern/servlet/*/url-pattern /servlet-mapping Releases The Apache Tomcat Team announces the immediate availability of new releases which include a fix to the invoker servlet. Apache Tomcat 4.1.12 Stable: http://jakarta.apache.org/builds/jakarta-tomcat-4.0/release/v4.1.12/ Apache Tomcat 4.0.5: http://jakarta.apache.org/builds/jakarta-tomcat-4.0/release/v4.0.5/ Remy -- To unsubscribe, e-mail: mailto:[EMAIL PROTECTED] For additional commands, e-mail: mailto:[EMAIL PROTECTED]
Re: [SECURITY] Apache Tomcat 4.x JSP source disclosure vulnerability
Would the following be vulnerable? 1) Use Jk only 2) do NOT use -- JkMount /servlet/* loadbalancer 3) But the invoker mapping is enabled Would they be vulnerable? I personally don't see a security flaw in this config. But does Jk also look for the text jsessionid being passed in the URL and automagically pass it along to tomcat? AFAIK - I thought a Rewrite rule needed to be added to have that behavior. Remy Maucherat wrote: A security vulnerability has been confirmed to exist in all Apache Tomcat 4.x releases (including Tomcat 4.0.4 and Tomcat 4.1.10), which allows to use a specially crafted URL to return the unprocessed source of a JSP page, or, under special circumstances, a static resource which would otherwise have been protected by security constraint, without the need for being properly authenticated. The cause - Using the invoker servlet in conjunction with the default servlet (responsible for handling static content in Tomcat) triggers this vulnerability. This particular configuration is available in the default Tomcat configuration. Workarounds --- An easy workaround exists for existing Tomcat installations, by disabling the invoker servlet in the default webapp configuration. In the $CATALINA_HOME/conf/web.xml file (on Windows, %CATALINA_HOME%\conf\web.xml), comment out or remove the following XML fragment: servlet-mapping servlet-nameinvoker/servlet-name url-pattern/servlet/*/url-pattern /servlet-mapping Releases The Apache Tomcat Team announces the immediate availability of new releases which include a fix to the invoker servlet. Apache Tomcat 4.1.12 Stable: http://jakarta.apache.org/builds/jakarta-tomcat-4.0/release/v4.1.12/ Apache Tomcat 4.0.5: http://jakarta.apache.org/builds/jakarta-tomcat-4.0/release/v4.0.5/ Remy -- To unsubscribe, e-mail: mailto:[EMAIL PROTECTED] For additional commands, e-mail: mailto:[EMAIL PROTECTED] -- To unsubscribe, e-mail: mailto:[EMAIL PROTECTED] For additional commands, e-mail: mailto:[EMAIL PROTECTED]
RE: [SECURITY] Apache Tomcat 4.x JSP source disclosure vulnerability
Evil question: does this vulnerability exist in Tomcat 3.2.3? Mitchell Evan Marx[EMAIL PROTECTED] ATT IP Network Configuration Provisioning Development -Original Message- From: Remy Maucherat [mailto:[EMAIL PROTECTED]] Sent: Tuesday, September 24, 2002 7:59 AM To: Tomcat Developers List; Tomcat Users List; announcements Subject: [SECURITY] Apache Tomcat 4.x JSP source disclosure vulnerability A security vulnerability has been confirmed to exist in all Apache Tomcat 4.x releases (including Tomcat 4.0.4 and Tomcat 4.1.10), which allows to use a specially crafted URL to return the unprocessed source of a JSP page, or, under special circumstances, a static resource which would otherwise have been protected by security constraint, without the need for being properly authenticated. The cause - Using the invoker servlet in conjunction with the default servlet (responsible for handling static content in Tomcat) triggers this vulnerability. This particular configuration is available in the default Tomcat configuration. Workarounds --- An easy workaround exists for existing Tomcat installations, by disabling the invoker servlet in the default webapp configuration. In the $CATALINA_HOME/conf/web.xml file (on Windows, %CATALINA_HOME%\conf\web.xml), comment out or remove the following XML fragment: servlet-mapping servlet-nameinvoker/servlet-name url-pattern/servlet/*/url-pattern /servlet-mapping Releases The Apache Tomcat Team announces the immediate availability of new releases which include a fix to the invoker servlet. Apache Tomcat 4.1.12 Stable: http://jakarta.apache.org/builds/jakarta-tomcat-4.0/release/v4.1.12/ Apache Tomcat 4.0.5: http://jakarta.apache.org/builds/jakarta-tomcat-4.0/release/v4.0.5/ Remy -- To unsubscribe, e-mail: mailto:[EMAIL PROTECTED] For additional commands, e-mail: mailto:[EMAIL PROTECTED] -- To unsubscribe, e-mail: mailto:[EMAIL PROTECTED] For additional commands, e-mail: mailto:[EMAIL PROTECTED]
Re: [SECURITY] Apache Tomcat 4.x JSP source disclosure vulnerability
Tim Funk wrote: Would the following be vulnerable? 1) Use Jk only 2) do NOT use -- JkMount /servlet/* loadbalancer 3) But the invoker mapping is enabled Would they be vulnerable? I personally don't see a security flaw in this config. But does Jk also look for the text jsessionid being passed in the URL and automagically pass it along to tomcat? AFAIK - I thought a Rewrite rule needed to be added to have that behavior. If you do end up passing any context/servlet/* URLs to Tomcat, then you're safe. However, I would still edit conf/web.xml as explained in the advisory to make sure there are no problems in the future. Remy -- To unsubscribe, e-mail: mailto:[EMAIL PROTECTED] For additional commands, e-mail: mailto:[EMAIL PROTECTED]
Re: [SECURITY] Apache Tomcat 4.x JSP source disclosure vulnerability
Remy Maucherat wrote: Tim Funk wrote: Would the following be vulnerable? 1) Use Jk only 2) do NOT use -- JkMount /servlet/* loadbalancer 3) But the invoker mapping is enabled Would they be vulnerable? I personally don't see a security flaw in this config. But does Jk also look for the text jsessionid being passed in the URL and automagically pass it along to tomcat? AFAIK - I thought a Rewrite rule needed to be added to have that behavior. If you do end up passing any context/servlet/* URLs to Tomcat, then you're safe. However, I would still edit conf/web.xml as explained in the advisory to make sure there are no problems in the future. Of course, this should read If you do NOT end up ;-) Remy -- To unsubscribe, e-mail: mailto:[EMAIL PROTECTED] For additional commands, e-mail: mailto:[EMAIL PROTECTED]
Re: [SECURITY] Apache Tomcat 4.x JSP source disclosure vulnerability
Marx, Mitchell E (Mitch), ALCNS wrote: Evil question: does this vulnerability exist in Tomcat 3.2.3? No. At worst it would be vulnerable to a distant cousin of the exploit. Remy -- To unsubscribe, e-mail: mailto:[EMAIL PROTECTED] For additional commands, e-mail: mailto:[EMAIL PROTECTED]
Re: [SECURITY] Apache Tomcat 4.x JSP source disclosure vulnerability
This may be true (though I have never tested it).
What's easier though? Upgrading a Tomcat server with a
patch or re-architecting your whole site to accomodate
for Velocity??
;-)
-Matt
--- Jon Scott Stevens [EMAIL PROTECTED] wrote:
on 2002/9/24 4:59 AM, Remy Maucherat
[EMAIL PROTECTED] wrote:
A security vulnerability has been confirmed to
exist in all Apache
Tomcat 4.x releases (including Tomcat 4.0.4 and
Tomcat 4.1.10), which
allows to use a specially crafted URL to return
the unprocessed source
of a JSP page, or, under special circumstances, a
static resource which
would otherwise have been protected by security
constraint, without the
need for being properly authenticated.
Once again...JSP sucks and Velocity is the right way
to go...you will never
have to worry about your container spilling your
beans (pun intended).
Given that Tomcat gets around 100k+
downloads/week...imagine how many
servers now need to be updated and how much money
and time that will cost to
do so?
http://jakarta.apache.org/velocity/
Wake up people. Velocity is faster and more secure
than JSP will ever be.
-jon
--
To unsubscribe, e-mail:
mailto:[EMAIL PROTECTED]
For additional commands, e-mail:
mailto:[EMAIL PROTECTED]
=
int myName() {
cout -Matt Fury \n;
return 0;
}
__
Do you Yahoo!?
New DSL Internet Access from SBC Yahoo!
http://sbc.yahoo.com
--
To unsubscribe, e-mail: mailto:[EMAIL PROTECTED]
For additional commands, e-mail: mailto:[EMAIL PROTECTED]
Re: [SECURITY] Apache Tomcat 4.x JSP source disclosure vulnerability
This list is for discussing Tomcat development, not velocity, web macro, et. al. The evangelizing for velocity is off topic in this list. JSP is part of Tomcat, live with it and move on. There are plenty of other forums for discussing the merits of one web templating technology vs another. Thanks, Glenn Bojan Smojver wrote: On Wed, 2002-09-25 at 07:31, Matt Fury wrote: What's easier though? Upgrading a Tomcat server with a patch or re-architecting your whole site to accomodate for Velocity?? Short term, upgrading Tomcat. Long term, doing it in Velocity. Bojan -- To unsubscribe, e-mail: mailto:[EMAIL PROTECTED] For additional commands, e-mail: mailto:[EMAIL PROTECTED] -- To unsubscribe, e-mail: mailto:[EMAIL PROTECTED] For additional commands, e-mail: mailto:[EMAIL PROTECTED]
Re: [SECURITY] Apache Tomcat 4.x JSP source disclosure vulnerability
On Tuesday 24 September 2002 05:26 pm, Jon Scott Stevens wrote: on 2002/9/24 4:59 AM, Remy Maucherat [EMAIL PROTECTED] wrote: A security vulnerability has been confirmed to exist in all Apache Tomcat 4.x releases (including Tomcat 4.0.4 and Tomcat 4.1.10), which allows to use a specially crafted URL to return the unprocessed source of a JSP page, or, under special circumstances, a static resource which would otherwise have been protected by security constraint, without the need for being properly authenticated. Once again...JSP sucks and Velocity is the right way to go...you will never have to worry about your container spilling your beans (pun intended). Perhaps you would prefer this exploit? http://localhost:8080/velexample/servlet/org.apache.catalina.servlets.DefaultServlet/sample.vm Horrors! Velocity is insecure! The DefaultServlet exploit is a general security problem in Tomcat. JSP may be somewhat more vulnerable, due to the (somewhat naieve) expectation that the source will be confidential, but it's not really JSP per se that is at fault. I wonder what could be done with the CGIServlet, for example. The root cause is the InvokerServlet. It's inherently insecure. It can be used not just to execute an arbitrary servlet, but to actually load any java class. And loading a class is not side-effect free. Given that Tomcat gets around 100k+ downloads/week...imagine how many servers now need to be updated and how much money and time that will cost to do so? http://jakarta.apache.org/velocity/ Wake up people. Velocity is faster and more secure than JSP will ever be. As long as it's running on an insecure container, it's really no safer. -jon -- To unsubscribe, e-mail: mailto:[EMAIL PROTECTED] For additional commands, e-mail: mailto:[EMAIL PROTECTED]
Re: [SECURITY] Apache Tomcat 4.x JSP source disclosure vulnerability
Quoting Glenn Nielsen [EMAIL PROTECTED]: This list is for discussing Tomcat development, not velocity, web macro, et. al. The evangelizing for velocity is off topic in this list. JSP is part of Tomcat, live with it and move on. There are plenty of other forums for discussing the merits of one web templating technology vs another. Sure. But it's fun :-) Bojan - This mail sent through IMP: http://horde.org/imp/ -- To unsubscribe, e-mail: mailto:[EMAIL PROTECTED] For additional commands, e-mail: mailto:[EMAIL PROTECTED]
Re: [SECURITY] Apache Tomcat 4.x JSP source disclosure vulnerability
Quoting Steve Downey [EMAIL PROTECTED]: Perhaps you would prefer this exploit? http://localhost:8080/velexample/servlet/org.apache.catalina.servlets.DefaultServlet/sample.vm Horrors! Velocity is insecure! The DefaultServlet exploit is a general security problem in Tomcat. JSP may be somewhat more vulnerable, due to the (somewhat naieve) expectation that the source will be confidential, but it's not really JSP per se that is at fault. Actually, there is a big difference here. You're assuming that Velocity macro pages are programs (well, classes) like JSP's and therefore probably contain security sensitive information. Usually what you'll see is something like this: #foreach($role in $roles) #if($fields.rolename $fields.rolename==$role.rolename) option selected=selected$role.rolename/option #else option$role.rolename/option #end #end This is a (very typical) snippet from a VM that does editing of Tomcat users/roles database in one of my applications. I don't care if people see that code at all because the template doesn't do anything but templating. The beef if elsewhere (i.e. MVC). Bojan PS. Glenn, my apologies, I was just answering a direct question. - This mail sent through IMP: http://horde.org/imp/ -- To unsubscribe, e-mail: mailto:[EMAIL PROTECTED] For additional commands, e-mail: mailto:[EMAIL PROTECTED]
