You are viewing a plain text version of this content. The canonical link for it is here.
Posted to dev@tomcat.apache.org by cr...@apache.org on 2001/08/09 21:43:00 UTC
cvs commit: jakarta-tomcat-4.0/catalina/src/share/org/apache/catalina/connector/http HttpProcessor.java
craigmcc 01/08/09 12:43:00
Modified: catalina/src/share/org/apache/catalina/connector/http
HttpProcessor.java
Log:
Make request URIs the contain "/..." (or any longer series of periods)
invalid. On some (all?) Windows platforms, this causes the OS to walk the
directory tree just like "../../.." type sequences do.
PR: Bugzilla #3062
Submitted by: peter_c60@hotmail.com
Revision Changes Path
1.35 +9 -4 jakarta-tomcat-4.0/catalina/src/share/org/apache/catalina/connector/http/HttpProcessor.java
Index: HttpProcessor.java
===================================================================
RCS file: /home/cvs/jakarta-tomcat-4.0/catalina/src/share/org/apache/catalina/connector/http/HttpProcessor.java,v
retrieving revision 1.34
retrieving revision 1.35
diff -u -r1.34 -r1.35
--- HttpProcessor.java 2001/07/26 05:31:05 1.34
+++ HttpProcessor.java 2001/08/09 19:43:00 1.35
@@ -1,6 +1,6 @@
-/* * $Header: /home/cvs/jakarta-tomcat-4.0/catalina/src/share/org/apache/catalina/connector/http/HttpProcessor.java,v 1.34 2001/07/26 05:31:05 remm Exp $
- * $Revision: 1.34 $
- * $Date: 2001/07/26 05:31:05 $
+/* * $Header: /home/cvs/jakarta-tomcat-4.0/catalina/src/share/org/apache/catalina/connector/http/HttpProcessor.java,v 1.35 2001/08/09 19:43:00 craigmcc Exp $
+ * $Revision: 1.35 $
+ * $Date: 2001/08/09 19:43:00 $
*
* ====================================================================
*
@@ -106,7 +106,7 @@
*
* @author Craig R. McClanahan
* @author Remy Maucherat
- * @version $Revision: 1.34 $ $Date: 2001/07/26 05:31:05 $
+ * @version $Revision: 1.35 $ $Date: 2001/08/09 19:43:00 $
*/
final class HttpProcessor
@@ -879,6 +879,11 @@
normalized = normalized.substring(0, index2) +
normalized.substring(index + 3);
}
+
+ // Declare occurrences of "/..." (three or more dots) to be invalid
+ // (on some Windows platforms this walks the directory tree!!!)
+ if (normalized.indexOf("/...") >= 0)
+ return (null);
// Return the normalized path that we have completed
return (normalized);
Re: cvs commit: jakarta-tomcat-4.0/catalina/src/share/org/apache/catalina/connector/http HttpProcessor.java
Posted by Incze Lajos <in...@mail.matav.hu>.
> > And: if a bug
> > then - just theoretically - is that a goood decision to program for bugs?
>
> What other choice would we have? Without doing this, there's nothing
> Tomcat could do to stop you from snooping the server's entire hard
> drive. And users would rightly say that Tomcat is broken if that were
> allowed.
>
> Of course, you could call case insensitivity on Windows a bug as well
> :-). Even if you don't, it's something that Tomcat has to deal with in
> order to conform to the specs that say request URIs are case sensitive.
I really was wonder just theoretically, and only speculating
where is a limit. Why not to follow a usual security scenario:
Bugtraq, illustrating (hopely on IIS server) the issues,
press release, I'm not familiar how to do that. Quietly
making a workaround leads allways to a looser position.
You will run extra code, even when an MS patch came out and
you'll be notified, or not. What to do, if the fix came out?
Leave your workaround in the code (for the sake of people
who don't know of it) or not?
On the other hand, if you documented this bug at the proper
places then all the trouble goes where it belongs to. If
tomcat works on solaris, but doesn't work on windows, and
MS doesn't fix a sec-hole, then users have a choice.
Don't know if I'm right or not, but I would go myself
on the bugtraq track.
incze
Re: cvs commit:
jakarta-tomcat-4.0/catalina/src/share/org/apache/catalina/connector/httpHttpProcessor.java
Posted by Glenn Nielsen <gl...@voyager.apg.more.net>.
"Craig R. McClanahan" wrote:
>
> On Fri, 10 Aug 2001, Incze Lajos wrote:
>
> > On Thu, Aug 09, 2001 at 07:43:00PM -0000, craigmcc@apache.org wrote:
> > > craigmcc 01/08/09 12:43:00
> > >
> > ...
> > > Make request URIs the contain "/..." (or any longer series of periods)
> > > invalid. On some (all?) Windows platforms, this causes the OS to walk the
> > > directory tree just like "../../.." type sequences do.
> > ...
> >
> > Is this a "feature" (I mean a documented thing) or a bug?
>
> IMHO it's a bug in the operating system, and it was a security flaw in
> Tomcat (which is not supposed to let you reference *anything* outside your
> web app's context).
>
> > And: if a bug
> > then - just theoretically - is that a goood decision to program for bugs?
>
> What other choice would we have? Without doing this, there's nothing
> Tomcat could do to stop you from snooping the server's entire hard
> drive. And users would rightly say that Tomcat is broken if that were
> allowed.
>
There is an easy way to protect the server without using custom code
to overcome some OS bug, start Tomcat with -security and use a security
policy which uses java.io.FilePermission's to restrict access to
directories and files. :-)
This is a very good example of why you should use the Java SecurityManager.
Regards,
Glenn
----------------------------------------------------------------------
Glenn Nielsen glenn@more.net | /* Spelin donut madder |
MOREnet System Programming | * if iz ina coment. |
Missouri Research and Education Network | */ |
----------------------------------------------------------------------
Re: cvs commit: jakarta-tomcat-4.0/catalina/src/share/org/apache/catalina/connector/http
HttpProcessor.java
Posted by "Craig R. McClanahan" <cr...@apache.org>.
On Fri, 10 Aug 2001, Incze Lajos wrote:
> On Thu, Aug 09, 2001 at 07:43:00PM -0000, craigmcc@apache.org wrote:
> > craigmcc 01/08/09 12:43:00
> >
> ...
> > Make request URIs the contain "/..." (or any longer series of periods)
> > invalid. On some (all?) Windows platforms, this causes the OS to walk the
> > directory tree just like "../../.." type sequences do.
> ...
>
> Is this a "feature" (I mean a documented thing) or a bug?
IMHO it's a bug in the operating system, and it was a security flaw in
Tomcat (which is not supposed to let you reference *anything* outside your
web app's context).
> And: if a bug
> then - just theoretically - is that a goood decision to program for bugs?
What other choice would we have? Without doing this, there's nothing
Tomcat could do to stop you from snooping the server's entire hard
drive. And users would rightly say that Tomcat is broken if that were
allowed.
Of course, you could call case insensitivity on Windows a bug as well
:-). Even if you don't, it's something that Tomcat has to deal with in
order to conform to the specs that say request URIs are case sensitive.
> Even if you get away with this thing at URL parsing you wil get it
> back at places that you can't control - you can't be safe until the
> bug is not fixed on the platform itself.
>
> (Otherwise on my NT4 (SP6) the ........ etc. works at the DOS prompt
> mostly like a single dot. So here are some "remain in place" commands:
> cd .
> cd ....
> cd .....................
>
> But:
> cd ................\............... type commands sometimes succeed,
> sometimes raise an "The system cannot find the path specified" message
> and I'm lazy to try to figure out what is the rule behind this
> boring error.)
>
But "cd" commands are not Tomcat's problem. You take your own risks :-)
when you run Tomcat on a platform that behaves like this -- all we can do
is make sure that *Tomcat* does not let you shoot yourself in the foot.
>
> incze
>
Craig
Re: cvs commit: jakarta-tomcat-4.0/catalina/src/share/org/apache/catalina/connector/http HttpProcessor.java
Posted by Incze Lajos <in...@mail.matav.hu>.
On Thu, Aug 09, 2001 at 07:43:00PM -0000, craigmcc@apache.org wrote:
> craigmcc 01/08/09 12:43:00
>
...
> Make request URIs the contain "/..." (or any longer series of periods)
> invalid. On some (all?) Windows platforms, this causes the OS to walk the
> directory tree just like "../../.." type sequences do.
...
Is this a "feature" (I mean a documented thing) or a bug? And: if a bug
then - just theoretically - is that a goood decision to program for bugs?
Even if you get away with this thing at URL parsing you wil get it
back at places that you can't control - you can't be safe until the
bug is not fixed on the platform itself.
(Otherwise on my NT4 (SP6) the ........ etc. works at the DOS prompt
mostly like a single dot. So here are some "remain in place" commands:
cd .
cd ....
cd .....................
But:
cd ................\............... type commands sometimes succeed,
sometimes raise an "The system cannot find the path specified" message
and I'm lazy to try to figure out what is the rule behind this
boring error.)
incze