This is similar to what I already implemented. The difficulty arises from
the fact the problem is not apparent until you actually attempt to create
the input stream. I tried lots of variations of creating URLs objects and
then turning them into strings and there was no reliable way to detect the
decoded/non-decode variations without creating the InputStream.
The problem really lies in the implementation of
sun.net.www.protocol.file.FileURLConnection. Costin's idea of creating a
Tomcat implementation that works the way we need it to work has some merit.
I'll look at what it would take implement a URLConnectionhandler.
> -----Original Message-----
> From: Mel Martinez [mailto:[EMAIL PROTECTED]]
> Sent: Saturday, April 07, 2001 10:21 AM
> To: [EMAIL PROTECTED]
> Subject: RE: [STATUS] Tomcat 3.2.2
>
>
>
> Mark,
>
> Re: the problem with the fact that some jdk1.2.2
> implementations may have the bug and others may not.
>
> Could you possibly put a preamble in a static
> initializer that explicitely tests the URL decoding of
> some static strings? If the bug occurs, set a (static
> final) flag? That would give you a simple (static
> final) boolean test on whether to double the decoding
> or not, which would be about as minimal a runtime
> performance hit as you could hope for.
>
> Just a wild thought from left field.
>
> Mel
>
> --- Marc Saegesser <[EMAIL PROTECTED]> wrote:
> > As usual, the problem turned out to be deeper then I
> > first expected.
> >
> > Here's what happened. There was a bug in 3.2.1 that
> > servlet paths and path
> > info weren't being decoded as required by the spec.
> > This was fixed in
> > 3.2.2.
> >
> > It also turns out that there was bug in JDK1.2.2
> > that caused %HH escape
> > characters in file: URLs to not be decoded. I
> > originally thought the bug
> > was in 1.3.0, but after re-reading the URL spec I
> > accept that the bug was
> > really in 1.2.2. The bottom line is that the
> > behavior of file URLs is
> > different on different versions of Java.
> >
> > Context.getResource() constructs a file: URL by
> > concatenating the context
> > root with the servlet path. On JDK1.3.0 systems,
> > this now results in the
> > servlet path getting decoded twice: once in
> > RequestUtil and once by URL.
> > Decoding URLs more than once causes all kinds of
> > security problems.
> >
> > So, given that file: URLs behave differently on
> > different system, we have to
> > adjust the input to the URL constructor in
> > Context.getResource() so that the
> > file names passed in on systems without the bug have
> > been URL encoded so
> > that the URL can then decode them and get the
> > correct file name.
> >
> > So now the question becomes determining if the
> > system has the file: URL bug.
> > I don't think you can just look at the version
> > number because not every
> > vendor's 1.2.2 implementation may be broken and
> > every vendor's 1.3.x
> > implementation may not be fixed. So it comes down
> > to checking the behavior
> > of URL to see what flavor you have. I've tried all
> > kinds of combinations of
> > toString(), toExternalForm(), sameFile(), etc. and
> > so far the only reliable
> > method I have for determining which version of URL
> > you have is to actually
> > use it to open an InputStream and see if it works.
> > For example a simple
> > routine could try to open file:%2e (i.e. the current
> > directory). If it gets
> > a FileNotFoundException then it assumes that it has
> > a broken URL
> > implementation, if it doesn't get an exception then
> > it assumes that the URL
> > implementation is correct. Context.getResource()
> > can now check if the URL
> > implementation is broken or not and do the right
> > thing.
> >
> > This fixes the security hole, but opens up a new
> > kind of attack. A
> > malicious user on a JDK1.2.2 server could create a
> > file called %2e in
> > Tomcat's working directory. This would cause Tomcat
> > to not find resources
> > that it legitimately should find. This better than
> > exposing the entire
> > server to prying eyes, but it still doesn't feel
> > right.
> >
> > I'm going to commit the fix as I have it now so that
> > others can review it
> > and maybe come up with a better approach. I'm now
> > planning to release beta
> > 3 Saturday morning (central US time).
> >
> >
> >
> > > -----Original Message-----
> > > From: Marc Saegesser
> > [mailto:[EMAIL PROTECTED]]
> > > Sent: Friday, April 06, 2001 11:29 AM
> > > To: [EMAIL PROTECTED]
> > > Subject: [STATUS] Tomcat 3.2.2
> > >
> > >
> > > I've got a fix for the URL double decode security
> > problem in Tomcat 3.2.2.
> > > I'm going to release Tomcat 3.2.2 beta 3 tonight
> > to make this fix publicly
> > > available. Because the only change in Beta 3 is
> > the security
> > > fix, this beta
> > > cycle will only be one week long. If no other
> > security issues are found,
> > > I'll call a vote for 3.2.2 final late next week.
> > >
> > >
> > >
> >
>
>
> __________________________________________________
> Do You Yahoo!?
> Get email at your own domain with Yahoo! Mail.
> http://personal.mail.yahoo.com/
