You are viewing a plain text version of this content. The canonical link for it is here.
Posted to users@tomcat.apache.org by Remy Maucherat <re...@apache.org> on 2002/09/24 13:59:15 UTC
[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-name>invoker</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: <ma...@jakarta.apache.org>
For additional commands, e-mail: <ma...@jakarta.apache.org>
[SECURITY] Apache Tomcat 4.x JSP source disclosure vulnerability;
Apache Tomcat 4.0.6 released
Posted by Remy Maucherat <re...@apache.org>.
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-name>invoker</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: <ma...@jakarta.apache.org>
For additional commands, e-mail: <ma...@jakarta.apache.org>
[SECURITY] Apache Tomcat 4.x JSP source disclosure vulnerability;
Apache Tomcat 4.0.6 released
Posted by Remy Maucherat <re...@apache.org>.
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-name>invoker</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: <ma...@jakarta.apache.org>
For additional commands, e-mail: <ma...@jakarta.apache.org>
Re: [SECURITY] Apache Tomcat 4.x JSP source disclosure vulnerability
Posted by Remy Maucherat <re...@apache.org>.
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: <ma...@jakarta.apache.org>
For additional commands, e-mail: <ma...@jakarta.apache.org>
Re: [SECURITY] Apache Tomcat 4.x JSP source disclosure vulnerability
Posted by Remy Maucherat <re...@apache.org>.
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: <ma...@jakarta.apache.org>
For additional commands, e-mail: <ma...@jakarta.apache.org>
Re: [SECURITY] Apache Tomcat 4.x JSP source disclosure vulnerability
Posted by Tim Funk <fu...@joedog.org>.
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-name>invoker</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:
> <ma...@jakarta.apache.org>
> For additional commands, e-mail:
> <ma...@jakarta.apache.org>
>
>
>
--
To unsubscribe, e-mail: <ma...@jakarta.apache.org>
For additional commands, e-mail: <ma...@jakarta.apache.org>
Re: [SECURITY] Apache Tomcat 4.x JSP source disclosure vulnerability
Posted by Bojan Smojver <bo...@rexursive.com>.
Quoting Steve Downey <st...@netfolio.com>:
> 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: <ma...@jakarta.apache.org>
For additional commands, e-mail: <ma...@jakarta.apache.org>
Re: [SECURITY] Apache Tomcat 4.x JSP source disclosure
vulnerability
Posted by Jon Scott Stevens <jo...@latchkey.com>.
on 2002/9/25 6:27 AM, "Costin Manolache" <cm...@yahoo.com> wrote:
> Well, this is not a very good policy IMO. Self-contained applications are
> a good thing ( IMO ).
Then store your templates in the WEB-INF directory. That is what we do with
Scarab, which is 100% self contained.
> 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.
Correct, but what is *encouraged* by default is to store them in the
webroot. Maybe you guys should fix that.
jakarta-tomcat-4.0.5/webapps/examples/jsp
-jon
--
StudioZ.tv /\ Bar/Nightclub/Entertainment
314 11th Street @ Folsom /\ San Francisco
http://studioz.tv/
--
To unsubscribe, e-mail: <ma...@jakarta.apache.org>
For additional commands, e-mail: <ma...@jakarta.apache.org>
Re: [SECURITY] Apache Tomcat 4.x JSP source disclosure vulnerability
Posted by Costin Manolache <cm...@yahoo.com>.
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: <ma...@jakarta.apache.org>
For additional commands, e-mail: <ma...@jakarta.apache.org>
Re: [SECURITY] Apache Tomcat 4.x JSP source disclosure
vulnerability
Posted by Jon Scott Stevens <jo...@latchkey.com>.
on 2002/9/24 5:15 PM, "Steve Downey" <st...@netfolio.com> wrote:
> http://localhost:8080/velexample/servlet/org.apache.catalina.servlets.DefaultS
> ervlet/sample.vm
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.
-jon
--
To unsubscribe, e-mail: <ma...@jakarta.apache.org>
For additional commands, e-mail: <ma...@jakarta.apache.org>
Re: [SECURITY] Apache Tomcat 4.x JSP source disclosure vulnerability
Posted by Steve Downey <st...@netfolio.com>.
On Tuesday 24 September 2002 05:26 pm, Jon Scott Stevens wrote:
> on 2002/9/24 4:59 AM, "Remy Maucherat" <re...@apache.org> 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: <ma...@jakarta.apache.org>
For additional commands, e-mail: <ma...@jakarta.apache.org>
Re: [SECURITY] Apache Tomcat 4.x JSP source disclosure vulnerability
Posted by Bojan Smojver <bo...@rexursive.com>.
Quoting Glenn Nielsen <gl...@mail.more.net>:
> 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: <ma...@jakarta.apache.org>
For additional commands, e-mail: <ma...@jakarta.apache.org>
Re: [SECURITY] Apache Tomcat 4.x JSP source disclosure vulnerability
Posted by Glenn Nielsen <gl...@mail.more.net>.
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: <ma...@jakarta.apache.org>
> For additional commands, e-mail: <ma...@jakarta.apache.org>
--
To unsubscribe, e-mail: <ma...@jakarta.apache.org>
For additional commands, e-mail: <ma...@jakarta.apache.org>
Re: [SECURITY] Apache Tomcat 4.x JSP source disclosure vulnerability
Posted by Matt Fury <ma...@yahoo.com>.
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 <bo...@rexursive.com> 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:
> <ma...@jakarta.apache.org>
> For additional commands, e-mail:
> <ma...@jakarta.apache.org>
>
=====
------------------------
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: <ma...@jakarta.apache.org>
For additional commands, e-mail: <ma...@jakarta.apache.org>
RE: [SECURITY] Apache Tomcat 4.x JSP source disclosure
vulnerability
Posted by Bob Herrmann <bo...@jadn.com>.
With power comes responsibility.
<% System.exit(1) %>
-bob
P.S. Yea, I know the SecurityManager can catch this, if enabled.
On Wed, 2002-09-25 at 21:22, Bojan Smojver wrote:
> Quoting Costin Manolache <cm...@yahoo.com>:
>
> > 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(999999));
> }
> -----------------------------------------------
>
> 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: <ma...@jakarta.apache.org>
> For additional commands, e-mail: <ma...@jakarta.apache.org>
--
Bob Herrmann <bo...@jadn.com>
--
To unsubscribe, e-mail: <ma...@jakarta.apache.org>
For additional commands, e-mail: <ma...@jakarta.apache.org>
RE: [SECURITY] Apache Tomcat 4.x JSP source disclosure vulnerability
Posted by Bojan Smojver <bo...@rexursive.com>.
Quoting Costin Manolache <cm...@yahoo.com>:
> 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: <ma...@jakarta.apache.org>
For additional commands, e-mail: <ma...@jakarta.apache.org>
RE: [SECURITY] Apache Tomcat 4.x JSP source disclosure vulnerability
Posted by Costin Manolache <cm...@yahoo.com>.
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: <ma...@jakarta.apache.org>
For additional commands, e-mail: <ma...@jakarta.apache.org>
Re: [OT] Re: [SECURITY] Apache Tomcat 4.x JSP source disclosure
vulnerability
Posted by co...@covalent.net.
On Fri, 27 Sep 2002, Geir Magnusson Jr. wrote:
> On 9/26/02 5:38 PM, "Bojan Smojver" <bo...@rexursive.com> wrote:
>
> [SNIP]
>
> > with them - quite the contrary. If you know what you're doing, you can
> > write great web applications in assembler, if you don't mind vomiting a
> > lot ;-)
>
> I actually like assembler. Keeps you focused :)
I actually like assembler too. It prevents you from writing bloatware,
and makes you understand a lot of stuff. Too bad so many people are
jumping directly to MVC and OO.
Probably not the best tool for web applications - that would be Perl.
BTW, have you looked at the velocity ant properties ? ( in
ant/proposal/embed ). I would like to contribute them
back to velocity ( and same for jxpath ), if it's ok with you.
( it's the stuff that enables velocity to be used in ant
properties - like ${vm:EXPRESSION} )
Costin
--
To unsubscribe, e-mail: <ma...@jakarta.apache.org>
For additional commands, e-mail: <ma...@jakarta.apache.org>
Re: [OT] Re: [SECURITY] Apache Tomcat 4.x JSP source disclosure
vulnerability
Posted by Costin Manlache <cm...@yahoo.com>.
Ops, didn't noticed the Cc.
Sorry for the noise on the list ( I hope it gets moderated :-)
Costin
On Fri, 27 Sep 2002, Geir Magnusson Jr. wrote:
> On 9/26/02 5:38 PM, "Bojan Smojver" <bo...@rexursive.com> wrote:
>
> [SNIP]
>
> > with them - quite the contrary. If you know what you're doing, you can
> > write great web applications in assembler, if you don't mind vomiting a
> > lot ;-)
>
> I actually like assembler. Keeps you focused :)
>
>
--
To unsubscribe, e-mail: <ma...@jakarta.apache.org>
For additional commands, e-mail: <ma...@jakarta.apache.org>
Re: [OT] Re: [SECURITY] Apache Tomcat 4.x JSP source disclosure
vulnerability
Posted by "Geir Magnusson Jr." <ge...@optonline.net>.
On 9/26/02 5:38 PM, "Bojan Smojver" <bo...@rexursive.com> wrote:
[SNIP]
> with them - quite the contrary. If you know what you're doing, you can
> write great web applications in assembler, if you don't mind vomiting a
> lot ;-)
I actually like assembler. Keeps you focused :)
--
Geir Magnusson Jr.
Research & Development, Adeptra Inc.
geirm@adeptra.com
+1-203-247-1713
--
To unsubscribe, e-mail: <ma...@jakarta.apache.org>
For additional commands, e-mail: <ma...@jakarta.apache.org>
Re: [OT] Re: [SECURITY] Apache Tomcat 4.x JSP source disclosure
vulnerability
Posted by Bojan Smojver <bo...@rexursive.com>.
I have promised not to use Tomcat-Dev for this, so I'm answering
privately and I'm sending a CC to Velocity-User list, where it belongs.
Nobody is treating users as stupid. Where are you getting the ideas
about me treating anyone as stupid from? I know it's hard for you to
understand because you're a brilliant programmer, but there a people out
there that can do great things with the look of the site, but
programming is not their thing - they are not stupid because of that.
And those people are web designers. IMHO, they play a very important
role in shaping a web application. If it doesn't look good, clients
won't like it.
However, they cannot be expected to understand a programming language of
Java's complexity. That's the job for the programmers.
Velocity is not taking away any power from anyone. It is just placing it
in the correct place. In the controller and model, where it should be.
I, for one, am sometimes both the web designer (and pretty poor at it
too) of some of my clients sites and the programmer. None of the power
of Java is out of my reach. As I said, it's sitting in the controller
and the model.
I don't feel I have to convert anyone to anything. But, when people ask
direct questions, I give them direct answers. And that is - JSP are
simply a bad idea. This doesn't mean you can't write great applications
with them - quite the contrary. If you know what you're doing, you can
write great web applications in assembler, if you don't mind vomiting a
lot ;-)
Bojan
On Thu, 2002-09-26 at 16:36, Costin Manolache wrote:
> Bojan Smojver wrote:
>
> > Quoting Bill Barker <wb...@wilshire.com>:
> >
> >> I'm agreeing with Costin. Please move this discussion to
> >> velocity-dev@jakarta.apache.org. 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: <ma...@jakarta.apache.org>
> For additional commands, e-mail: <ma...@jakarta.apache.org>
>
--
To unsubscribe, e-mail: <ma...@jakarta.apache.org>
For additional commands, e-mail: <ma...@jakarta.apache.org>
Re: [OT] Re: [SECURITY] Apache Tomcat 4.x JSP source disclosure vulnerability
Posted by Costin Manolache <cm...@yahoo.com>.
Bojan Smojver wrote:
> Quoting Bill Barker <wb...@wilshire.com>:
>
>> I'm agreeing with Costin. Please move this discussion to
>> velocity-dev@jakarta.apache.org. 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: <ma...@jakarta.apache.org>
For additional commands, e-mail: <ma...@jakarta.apache.org>
Re: [OT] Re: [SECURITY] Apache Tomcat 4.x JSP source disclosure vulnerability
Posted by Bojan Smojver <bo...@rexursive.com>.
Quoting Bill Barker <wb...@wilshire.com>:
> I'm agreeing with Costin. Please move this discussion to
> velocity-dev@jakarta.apache.org. 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: <ma...@jakarta.apache.org>
For additional commands, e-mail: <ma...@jakarta.apache.org>
[OT] Re: [SECURITY] Apache Tomcat 4.x JSP source disclosure vulnerability
Posted by Bill Barker <wb...@wilshire.com>.
I'm agreeing with Costin. Please move this discussion to
velocity-dev@jakarta.apache.org. It is off-topic here.
----- Original Message -----
From: "Bojan Smojver" <bo...@rexursive.com>
To: "Tomcat Developers List" <to...@jakarta.apache.org>
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 <fu...@joedog.org>:
>
> > 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 = "0000000000000000000000000000000000000000000000000000" )
> > #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(999999));
> > > }
> > > -----------------------------------------------
> > >
> >
> >
> > --
> > To unsubscribe, e-mail:
<ma...@jakarta.apache.org>
> > For additional commands, e-mail:
<ma...@jakarta.apache.org>
> >
> >
>
>
>
>
> -------------------------------------------------
> This mail sent through IMP: http://horde.org/imp/
>
> --
> To unsubscribe, e-mail:
<ma...@jakarta.apache.org>
> For additional commands, e-mail:
<ma...@jakarta.apache.org>
>
--
To unsubscribe, e-mail: <ma...@jakarta.apache.org>
For additional commands, e-mail: <ma...@jakarta.apache.org>
Re: Velocity (was RE: [SECURITY] Apache Tomcat 4.x JSP source
disclosure vulnerability)
Posted by Bojan Smojver <bo...@rexursive.com>.
I have promised not to use Tomcat-Dev for this, so I'm answering
privately and I'm sending a CC to Velocity-User list, where it belongs.
That's an excellent point and is exactly what I'm talking about. Again,
who creates the context object? The programmers, NOT the web designers.
As for YATL, anyone with half a brain and one afternoon can learn
Velocity. JSP is a completely different story because it's Java.
On the topic of programming in Velocity. Well, I've seen some really
complicated code out there. And you know what, it's all crap. The code
beyond simple if's and foreach directives should not be in any template
but rather in the controller or the model, written in Java, by the
programmers. If programmers are forcing designers to write complicated
Velocity constructs or are doing it themselves, they are asking for
trouble.
Bojan
On Fri, 2002-09-27 at 00:23, Dennis Doubleday wrote:
> 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:bojan@rexursive.com]
> > 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 <fu...@joedog.org>:
> >
> > > 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 =
> > "0000000000000000000000000000000000000000000000000000" )
> > > #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(999999));
> > > > }
> > > > -----------------------------------------------
>
>
> --
> To unsubscribe, e-mail: <ma...@jakarta.apache.org>
> For additional commands, e-mail: <ma...@jakarta.apache.org>
>
--
To unsubscribe, e-mail: <ma...@jakarta.apache.org>
For additional commands, e-mail: <ma...@jakarta.apache.org>
Re: Velocity (was RE: [SECURITY] Apache Tomcat 4.x JSP source disclosure vulnerability)
Posted by Dennis Doubleday <de...@righthandmanager.com>.
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:bojan@rexursive.com]
> 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 <fu...@joedog.org>:
>
> > 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 =
> "0000000000000000000000000000000000000000000000000000" )
> > #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(999999));
> > > }
> > > -----------------------------------------------
--
To unsubscribe, e-mail: <ma...@jakarta.apache.org>
For additional commands, e-mail: <ma...@jakarta.apache.org>
Re: [SECURITY] Apache Tomcat 4.x JSP source disclosure vulnerability
Posted by Bojan Smojver <bo...@rexursive.com>.
Not if:
runtime.interpolate.string.literals = false
Bojan
Quoting Tim Funk <fu...@joedog.org>:
> 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 = "0000000000000000000000000000000000000000000000000000" )
> #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(999999));
> > }
> > -----------------------------------------------
> >
>
>
> --
> To unsubscribe, e-mail: <ma...@jakarta.apache.org>
> For additional commands, e-mail: <ma...@jakarta.apache.org>
>
>
-------------------------------------------------
This mail sent through IMP: http://horde.org/imp/
--
To unsubscribe, e-mail: <ma...@jakarta.apache.org>
For additional commands, e-mail: <ma...@jakarta.apache.org>
Re: [SECURITY] Apache Tomcat 4.x JSP source disclosure vulnerability
Posted by Tim Funk <fu...@joedog.org>.
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 = "0000000000000000000000000000000000000000000000000000" )
#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(999999));
> }
> -----------------------------------------------
>
--
To unsubscribe, e-mail: <ma...@jakarta.apache.org>
For additional commands, e-mail: <ma...@jakarta.apache.org>
RE: [SECURITY] Apache Tomcat 4.x JSP source disclosure vulnerability
Posted by Bojan Smojver <bo...@rexursive.com>.
Quoting Costin Manolache <cm...@yahoo.com>:
> 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(999999));
}
-----------------------------------------------
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: <ma...@jakarta.apache.org>
For additional commands, e-mail: <ma...@jakarta.apache.org>
RE: [SECURITY] Apache Tomcat 4.x JSP source disclosure vulnerability
Posted by Costin Manolache <cm...@yahoo.com>.
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: <ma...@jakarta.apache.org>
For additional commands, e-mail: <ma...@jakarta.apache.org>
RE: [SECURITY] Apache Tomcat 4.x JSP source disclosure vulnerability
Posted by Bojan Smojver <bo...@rexursive.com>.
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: <ma...@jakarta.apache.org>
For additional commands, e-mail: <ma...@jakarta.apache.org>
RE: [SECURITY] Apache Tomcat 4.x JSP source disclosure vulnerability
Posted by John Trollinger <ja...@trollingers.com>.
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:bojan@rexursive.com]
> 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-> unsubscribe@jakarta.apache.org>
> For
> additional commands,
> e-mail: <ma...@jakarta.apache.org>
>
--
To unsubscribe, e-mail: <ma...@jakarta.apache.org>
For additional commands, e-mail: <ma...@jakarta.apache.org>
Re: [SECURITY] Apache Tomcat 4.x JSP source disclosure vulnerability
Posted by Bojan Smojver <bo...@rexursive.com>.
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: <ma...@jakarta.apache.org>
For additional commands, e-mail: <ma...@jakarta.apache.org>
Re: [SECURITY] Apache Tomcat 4.x JSP source disclosure vulnerability
Posted by Matt Fury <ma...@yahoo.com>.
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 <jo...@latchkey.com> wrote:
> on 2002/9/24 4:59 AM, "Remy Maucherat"
> <re...@apache.org> 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:
> <ma...@jakarta.apache.org>
> For additional commands, e-mail:
> <ma...@jakarta.apache.org>
>
=====
------------------------
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: <ma...@jakarta.apache.org>
For additional commands, e-mail: <ma...@jakarta.apache.org>
Re: [SECURITY] Apache Tomcat 4.x JSP source disclosure
vulnerability
Posted by Jon Scott Stevens <jo...@latchkey.com>.
on 2002/9/24 4:59 AM, "Remy Maucherat" <re...@apache.org> 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: <ma...@jakarta.apache.org>
For additional commands, e-mail: <ma...@jakarta.apache.org>
Re: [SECURITY] Apache Tomcat 4.x JSP source disclosure
vulnerability
Posted by Jon Scott Stevens <jo...@latchkey.com>.
on 2002/9/24 4:59 AM, "Remy Maucherat" <re...@apache.org> 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: <ma...@jakarta.apache.org>
For additional commands, e-mail: <ma...@jakarta.apache.org>