You are viewing a plain text version of this content. The canonical link for it is here.
Posted to dev@tomcat.apache.org by Marc Saegesser <ma...@apropos.com> on 2001/04/06 18:29:27 UTC
[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.
Re: database access problem
Posted by Christopher Cain <cc...@mhsoftware.com>.
Asim:
This is not the appropriate list for a JDBC question. This list is for
Tomcat-related questions. However, in answer to your question ...
I am surprised that this code works even in Access. The SQL you are
using actually should not return any rows at all. It is an INSERT
operation, not a SELECT statement. Given the SQL, the operation on g
would correctly be:
int iRecordsInserted = g.executeUpdate();
Using the executeQuery() method with an INSERT statement is more or less
invalid. Some driver implementations may try to handle it, which is why
your Access tests may have worked, but in general it is a very bad idea.
If you need to iterate the inserted records, you will need to do one of
two things. One way is simply to issue a SELECT query after the INSERT
which selects the inserted records. The other, and better, option would
be to create a stored procedure that does the INSERT and then returns
the records you want. See the prepareCall() methods on Connection for
more info on calling stored procedures in JDBC.
- Christopher
Asim Ghaffar wrote:
>
> Hello Friends!
> I am in real difficult situation so i need some quick advice. I am making a
> search engine. I did all my testing on MS Acess. So far so good. But now
> when i switched to Oracle and SQL Server i am getting a very odd problem
> (same in oravle and SQL).
> here is my code.
>
> 1 try {
> 2 ResultSet results = g.executeQuery(); //
> 3 while (results.next()) {
> 4 String u = results.getString("u");
> 5 String t = results.getString("T");
> 6 String s = (new Integer(results.getInt("S"))).toString();
> 7 String k = results.getString("K"); // Exception is
> thrown here at this line
> 8 String a = results.getString("P");
> 9 String d = results.getString("D");
> 10 String m = (new Integer(results.getInt("I"))).toString();
> 11 String l = results.getString("L");
> 12 String o = (new Integer(results.getInt("O"))).toString();
> 13 String st = results.getTimestamp("St").toString();
> 14 }
> 15 }catch (SQLException sqle){
> sqle.printStackTrace();
> }
>
> where g = connection.prepareStatement("INSERT INTO HITLIST SELECT SITES.*,1
> AS SCORE FROM SITES WHERE SITES.PAGETEXT LIKE '%pakistan%'");
>
> Now on line # 7 i am getting the exception
> in SQL Server it is [Microsoft][ODBC SQL Server Driver]Invalid Descriptor
> Index
> in Oracle it is some jdbc exeption about invalid column number
>
> Now if i switch the wors with each other error again come on same line
> number not statement.
> I debugged using jbuilder and in the middle of execution all
> resultset.getDataType("columnName") become inavlid even those which are on
> lines above. So badically whole result set gets corrupted.
> Same code is running fine in MS Access. Any clue what can be the reason for
> this. Where else i can get help from.
> thanking you in advance. I u have any clue do email me.
> bye
database access problem
Posted by Asim Ghaffar <u9...@giki.edu.pk>.
Hello Friends!
I am in real difficult situation so i need some quick advice. I am making a
search engine. I did all my testing on MS Acess. So far so good. But now
when i switched to Oracle and SQL Server i am getting a very odd problem
(same in oravle and SQL).
here is my code.
1 try {
2 ResultSet results = g.executeQuery(); //
3 while (results.next()) {
4 String u = results.getString("u");
5 String t = results.getString("T");
6 String s = (new Integer(results.getInt("S"))).toString();
7 String k = results.getString("K"); // Exception is
thrown here at this line
8 String a = results.getString("P");
9 String d = results.getString("D");
10 String m = (new Integer(results.getInt("I"))).toString();
11 String l = results.getString("L");
12 String o = (new Integer(results.getInt("O"))).toString();
13 String st = results.getTimestamp("St").toString();
14 }
15 }catch (SQLException sqle){
sqle.printStackTrace();
}
where g = connection.prepareStatement("INSERT INTO HITLIST SELECT SITES.*,1
AS SCORE FROM SITES WHERE SITES.PAGETEXT LIKE '%pakistan%'");
Now on line # 7 i am getting the exception
in SQL Server it is [Microsoft][ODBC SQL Server Driver]Invalid Descriptor
Index
in Oracle it is some jdbc exeption about invalid column number
Now if i switch the wors with each other error again come on same line
number not statement.
I debugged using jbuilder and in the middle of execution all
resultset.getDataType("columnName") become inavlid even those which are on
lines above. So badically whole result set gets corrupted.
Same code is running fine in MS Access. Any clue what can be the reason for
this. Where else i can get help from.
thanking you in advance. I u have any clue do email me.
bye
RE: [STATUS] Tomcat 3.2.2
Posted by Marc Saegesser <ma...@apropos.com>.
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: cmanolache@yahoo.com [mailto:cmanolache@yahoo.com]
> Sent: Saturday, April 07, 2001 11:15 AM
> To: tomcat-dev@jakarta.apache.org
> 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:melaquias@yahoo.com]
> > > Sent: Saturday, April 07, 2001 10:21 AM
> > > To: tomcat-dev@jakarta.apache.org
> > > 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 <ma...@apropos.com> 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:marc.saegesser@apropos.com]
> > > > > Sent: Friday, April 06, 2001 11:29 AM
> > > > > To: tomcat-dev@jakarta.apache.org
> > > > > 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/
> >
RE: [STATUS] Tomcat 3.2.2
Posted by cm...@yahoo.com.
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:melaquias@yahoo.com]
> > Sent: Saturday, April 07, 2001 10:21 AM
> > To: tomcat-dev@jakarta.apache.org
> > 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 <ma...@apropos.com> 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:marc.saegesser@apropos.com]
> > > > Sent: Friday, April 06, 2001 11:29 AM
> > > > To: tomcat-dev@jakarta.apache.org
> > > > 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/
>
RE: [STATUS] Tomcat 3.2.2
Posted by Marc Saegesser <ma...@apropos.com>.
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:melaquias@yahoo.com]
> Sent: Saturday, April 07, 2001 10:21 AM
> To: tomcat-dev@jakarta.apache.org
> 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 <ma...@apropos.com> 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:marc.saegesser@apropos.com]
> > > Sent: Friday, April 06, 2001 11:29 AM
> > > To: tomcat-dev@jakarta.apache.org
> > > 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/
RE: [STATUS] Tomcat 3.2.2
Posted by Mel Martinez <me...@yahoo.com>.
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 <ma...@apropos.com> 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:marc.saegesser@apropos.com]
> > Sent: Friday, April 06, 2001 11:29 AM
> > To: tomcat-dev@jakarta.apache.org
> > 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/
RE: [STATUS] Tomcat 3.2.2
Posted by cm...@yahoo.com.
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:marc.saegesser@apropos.com]
> > Sent: Friday, April 06, 2001 11:29 AM
> > To: tomcat-dev@jakarta.apache.org
> > 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.
> >
> >
> >
>
RE: [STATUS] Tomcat 3.2.2
Posted by Marc Saegesser <ma...@apropos.com>.
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:marc.saegesser@apropos.com]
> Sent: Friday, April 06, 2001 11:29 AM
> To: tomcat-dev@jakarta.apache.org
> 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.
>
>
>