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/
