Based on the number of bug reports against FileURLConnection it would appear
that getting this implemented correclty probably isn't trivial.
The double decode problem is caused by calling Context.getResource() for a
name that came from the request URI (servlet path or path info) because
these strings have already been decoded once.
The spec doesn't say clearly whether the string passed to getResource() may
contain URL escapes or not, but since it does return a URL and it is
accessing resources within a web application, I think it is fair to assume
that these strings *may* contain URL escapes.
So here's what I propose:
1) The implentation of getResource() and getResourceAsStream() will remain
unchanged. On JDK 1.2.2 systems this means that URL escapes won't work due
to the FileURLConnection bug. On 1.3.x systems, URL escapes will work
correctly.
2) If any Tomcat or Jasper code needs to call getResource() or
getResourceAsStream() it will first determine that the name doesn't contain
any URL escapes. If it does it will return a 404 response. We could add a
new getSafeResource() method
This lets servlet and JSP authors call getResource() with their own single
escaped strings, but double escaped strings from the client won't be
allowed.
> -----Original Message-----
> From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED]]
> Sent: Saturday, April 07, 2001 11:15 AM
> To: [EMAIL PROTECTED]
> Subject: RE: [STATUS] Tomcat 3.2.2
>
>
> On Sat, 7 Apr 2001, Marc Saegesser wrote:
>
> > 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.
>
> It seems the idea is not that good - URL is final, and changing the
> file: connection seems to be a bigger hack ( i.e. will affect all VMs,
> including the good ones ) than detecting a bad VM and fixing the URL.
>
> But on a second tought, and after a bit of reading in the Apache sources,
> I think we are on the wrong track.
>
> I think that instead of fixing the code to deal with all possible
> encoding
> tricks we should just report "invalid request" if we detect double
> encoding or %00 or anything suspicious ( Apache does that, we should do
> the same at least for consistency ). Of course, that means some files
> will not work - i.e. if you have a file named "foo%20bar%00" ( a valid
> file name - "foo bar" will work ), you'll not be able to request it. But
> I would rather have this as a bug than deal with security issues.
>
>
> Costin
>
>
>
>
>
> >
> > > -----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/
> >
