Marc,
What about removing the use of URL ? We can create a local URL object that
works in a deterministic way - that would be much cleaner than guessing
the OS and doing workarounds.
Costin
On Fri, 6 Apr 2001, Marc Saegesser 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.
> >
> >
> >
>
