You are viewing a plain text version of this content. The canonical link for it is here.
Posted to dev@tomcat.apache.org by Paul Sundling <to...@tkz.net> on 2003/08/13 04:11:37 UTC
Re: Fwd: Re: security hole on windows tomcat?
Yes, adding
-Dsun.io.useCanonCaches=false
to the tomcat seemed to fix the security hole I discovered on my 4.1.24 tomcat on Windows XP using JDK 1.4.2. Great job finding a solution. It's a testament to open source and cooperation. Fortunately it's JSP source it's showing and people should have anything worth seeing in their servlets or EJBs anyway. :)
Paul Sundling
Jeff Tulley wrote:
>I just wanted to make sure you saw this -- Jeanfrancois made the
>connection that this issue has a known workaround, so you don't have to
>backrev your JVM if you don't want to.
>
>I tried this on Windows XP and NetWare and it worked in both places...
>
>Jeff Tulley (jtulley@novell.com)
>(801)861-5322
>Novell, Inc., The Leading Provider of Net Business Solutions
>http://www.novell.com
>
>
>
>>>>jfarcand@apache.org 8/12/03 7:08:50 PM >>>
>>>>
>>>>
>Sorry I've just realize this thread may be related to bugtraq #4895132
>
>(thanks to Jeff for the wake up mail on tomcat-dev ;-) ). The
>workaround
>is to add the following property when starting Tomcat:
>
>-Dsun.io.useCanonCaches=false
>
>Can someone try it and let me know if it change something. If this is
>not working, then point me to a very simple test case and I will file a
>
>new bugtraq bug.
>
>-- Jeanfrancois
>
>
>Eric J. Pinnell wrote:
>
>
>
>>I think at this point this might be a worthwile canidate for Sun's
>>bugparade. At least get it on their radars (if they don't know about
>>
>>
>it
>
>
>>already). It's interesting that the bug doesn't show up in Tomcat
>>
>>
>4.1.27.
>
>
>>When 1.4.2 was released 4.1.24 was the latest stable build.
>>
>>Regardless the JDK/appserver/whatever should never puke it's guts and
>>
>>
>spit
>
>
>>out the source code when it gets a request it doesn't know how to
>>
>>
>deal
>
>
>>with. Upon failure it should result in some kind of error. Sun
>>
>>
>might
>
>
>>care about this...
>>
>>-e
>>
>>On Tue, 12 Aug 2003, Jeff Tulley wrote:
>>
>>
>>
>>
>>
>>>It is highly possible that this is dependent on the JVM you have
>>>installed. I actually finally WAS able to see this on Windows XP,
>>>
>>>
>but
>
>
>>>only if Tomcat was running on JVM 1.4.2. The problem did NOT happen
>>>with 1.4.1. Of course, JVM version is the one item I left off of my
>>>"poll" in my email below. :)
>>>
>>>I'm trying to verify this on other OS's and track down what the
>>>
>>>
>actual
>
>
>>>problem is.
>>>
>>>But, if you run Tomcat on JVM 1.4.2, verify if you have this
>>>
>>>
>problem.
>
>
>>>Jeff Tulley (jtulley@novell.com)
>>>(801)861-5322
>>>Novell, Inc., The Leading Provider of Net Business Solutions
>>>http://www.novell.com
>>>
>>>
>>>
>>>
>>>
>>>>>>mpnix@optusnet.com.au 8/12/03 4:10:53 PM >>>
>>>>>>
>>>>>>
>>>>>>
>>>>>>
>>>Tomcat 4.0.6 on Win2K via direct connection to Tomcat on localhost
>>>
>>>
>via
>
>
>>>either port 8080 or port 80 - pages return fine without the %20
>>>suffix,
>>>always return http 404 with the suffix.
>>>
>>>Murray
>>>-----Original Message-----
>>>From: Jeff Tulley [mailto:JTULLEY@novell.com]
>>>Sent: Wednesday, 13 August 2003 02:41
>>>To: tomcat-user@jakarta.apache.org
>>>Subject: RE: security hole on windows tomcat?
>>>
>>>
>>>So this issue is confusing. It seems that indeed there IS an issue,
>>>though most cannot see a problem.
>>>Talking to some people off-list, it seems that some think it is a
>>>
>>>
>JK2
>
>
>>>/
>>>workers2.properties issue. But I'm pretty sure that others have
>>>
>>>
>seen
>
>
>>>this going directly to port 8080.
>>>We probably need to take a quick poll:
>>>
>>>If you have seen this security problem of being able to view JSP
>>>source, in what scenario(s)?
>>>
>>>Tomcat version
>>>OS version
>>>Directly to Tomcat ("8080") or through Apache - JK or JK2?
>>>(If you've seen the problem, please include your workers or
>>>workers2.properties file, with a .txt extension)
>>>Browser version(s)
>>>url's where this was seen or not seen
>>>
>>>If you have seen this in multiple scenarios, and not in others,
>>>
>>>
>please
>
>
>>>list each separately.
>>>
>>>
>>>I have NOT seen it in the following scenarios:
>>>
>>>Tomcat 4.1.18, 4.1.24, 4.1.26, 4.1.27
>>>Windows 2000 5.00.2195 Service Pack 4
>>>Directly to port 8080
>>>Internet Explorer 6.0.2800.1106 with all security patches up to date
>>>I tried http://(url):8080/index.jsp%20
>>>
>>>Tomcat 4.1.18, 4.1.24, 4.1.26, fairly standard distributions (only
>>>adding one JNDIRealm beyond the default config)
>>>Novell NetWare 6.5
>>>Directly to port 8080, and through Apache - mod_jk.nlm
>>>Internet Explorer 6.0.2800.1106 with all security patches up to date
>>>I tried http://(url):8080/index.jsp%20 and
>>>https://(url)/tomcat/admin/index.jsp%20
>>>
>>>
>>>Hopefully this mail gets through; I haven't been seeing my emails
>>>
>>>
>show
>
>
>>>up on tomcat-user for some reason (I un/resubscribed today...)
>>>
>>>It would be really good to get to the bottom of this!
>>>
>>>Jeff Tulley (jtulley@novell.com)
>>>(801)861-5322
>>>Novell, Inc., The Leading Provider of Net Business Solutions
>>>http://www.novell.com
>>>
>>>
>>>
>>>
>>>
>>>>>>ccox@cincom.com 8/12/03 6:02:55 AM >>>
>>>>>>
>>>>>>
>>>>>>
>>>>>>
>>>can you turn on debugging for the default servlet(conf/web.xml) and
>>>also
>>>turn on the requestdumpervalve(server.xml) and post the log.
>>>
>>>
>>>
>
>
Re: Fwd: Re: security hole on windows tomcat?
Posted by Reshat Sabiq <sa...@purdue.edu>.
If the bug was caused by adding %20 to a page/folder in URL, then i
didn't reproduce it in Tomcat 5. I got 404 (the only bad thing is that
404's don't appear to be customizable with error-page directives in
web.xml).
What would be a good list to watch for these kinds of bugs in Tomcat?
Thanks.
Paul Sundling wrote:
> Yes, adding
>
> -Dsun.io.useCanonCaches=false
>
> to the tomcat seemed to fix the security hole I discovered on my
> 4.1.24 tomcat on Windows XP using JDK 1.4.2. Great job finding a
> solution. It's a testament to open source and cooperation.
> Fortunately it's JSP source it's showing and people should have
> anything worth seeing in their servlets or EJBs anyway. :)
> Paul Sundling
>
>
> Jeff Tulley wrote:
>
>> I just wanted to make sure you saw this -- Jeanfrancois made the
>> connection that this issue has a known workaround, so you don't have to
>> backrev your JVM if you don't want to.
>>
>> I tried this on Windows XP and NetWare and it worked in both places...
>>
>> Jeff Tulley (jtulley@novell.com)
>> (801)861-5322
>> Novell, Inc., The Leading Provider of Net Business Solutions
>> http://www.novell.com
>>
>>
>>
>>>>> jfarcand@apache.org 8/12/03 7:08:50 PM >>>
>>>>>
>>>>
>> Sorry I've just realize this thread may be related to bugtraq #4895132
>> (thanks to Jeff for the wake up mail on tomcat-dev ;-) ). The
>> workaround is to add the following property when starting Tomcat:
>>
>> -Dsun.io.useCanonCaches=false
>>
>> Can someone try it and let me know if it change something. If this is
>> not working, then point me to a very simple test case and I will file a
>>
>> new bugtraq bug.
>>
>> -- Jeanfrancois
>>
>>
>> Eric J. Pinnell wrote:
>>
>>
>>
>>> I think at this point this might be a worthwile canidate for Sun's
>>> bugparade. At least get it on their radars (if they don't know about
>>>
>>
>> it
>>
>>
>>> already). It's interesting that the bug doesn't show up in Tomcat
>>>
>>
>> 4.1.27.
>>
>>
>>> When 1.4.2 was released 4.1.24 was the latest stable build.
>>>
>>> Regardless the JDK/appserver/whatever should never puke it's guts and
>>>
>>
>> spit
>>
>>
>>> out the source code when it gets a request it doesn't know how to
>>>
>>
>> deal
>>
>>
>>> with. Upon failure it should result in some kind of error. Sun
>>>
>>
>> might
>>
>>
>>> care about this...
>>>
>>> -e
>>>
>>> On Tue, 12 Aug 2003, Jeff Tulley wrote:
>>>
>>>
>>>
>>>
>>>
>>>> It is highly possible that this is dependent on the JVM you have
>>>> installed. I actually finally WAS able to see this on Windows XP,
>>>>
>>>
>> but
>>
>>
>>>> only if Tomcat was running on JVM 1.4.2. The problem did NOT happen
>>>> with 1.4.1. Of course, JVM version is the one item I left off of my
>>>> "poll" in my email below. :)
>>>>
>>>> I'm trying to verify this on other OS's and track down what the
>>>>
>>>
>> actual
>>
>>
>>>> problem is.
>>>>
>>>> But, if you run Tomcat on JVM 1.4.2, verify if you have this
>>>>
>>>
>> problem.
>>
>>
>>>> Jeff Tulley (jtulley@novell.com)
>>>> (801)861-5322
>>>> Novell, Inc., The Leading Provider of Net Business Solutions
>>>> http://www.novell.com
>>>>
>>>>
>>>>
>>>>>>> mpnix@optusnet.com.au 8/12/03 4:10:53 PM >>>
>>>>>>>
>>>>>>>
>>>>>>
>>>> Tomcat 4.0.6 on Win2K via direct connection to Tomcat on localhost
>>>>
>>>
>> via
>>
>>
>>>> either port 8080 or port 80 - pages return fine without the %20
>>>> suffix,
>>>> always return http 404 with the suffix.
>>>>
>>>> Murray
>>>> -----Original Message-----
>>>> From: Jeff Tulley [mailto:JTULLEY@novell.com] Sent: Wednesday, 13
>>>> August 2003 02:41
>>>> To: tomcat-user@jakarta.apache.org Subject: RE: security hole on
>>>> windows tomcat?
>>>>
>>>>
>>>> So this issue is confusing. It seems that indeed there IS an issue,
>>>> though most cannot see a problem.
>>>> Talking to some people off-list, it seems that some think it is a
>>>>
>>>
>> JK2
>>
>>
>>>> /
>>>> workers2.properties issue. But I'm pretty sure that others have
>>>>
>>>
>> seen
>>
>>
>>>> this going directly to port 8080.
>>>> We probably need to take a quick poll:
>>>>
>>>> If you have seen this security problem of being able to view JSP
>>>> source, in what scenario(s)?
>>>>
>>>> Tomcat version
>>>> OS version
>>>> Directly to Tomcat ("8080") or through Apache - JK or JK2?
>>>> (If you've seen the problem, please include your workers or
>>>> workers2.properties file, with a .txt extension)
>>>> Browser version(s)
>>>> url's where this was seen or not seen
>>>>
>>>> If you have seen this in multiple scenarios, and not in others,
>>>>
>>>
>> please
>>
>>
>>>> list each separately.
>>>>
>>>>
>>>> I have NOT seen it in the following scenarios:
>>>>
>>>> Tomcat 4.1.18, 4.1.24, 4.1.26, 4.1.27
>>>> Windows 2000 5.00.2195 Service Pack 4
>>>> Directly to port 8080
>>>> Internet Explorer 6.0.2800.1106 with all security patches up to date
>>>> I tried http://(url):8080/index.jsp%20
>>>> Tomcat 4.1.18, 4.1.24, 4.1.26, fairly standard distributions (only
>>>> adding one JNDIRealm beyond the default config)
>>>> Novell NetWare 6.5
>>>> Directly to port 8080, and through Apache - mod_jk.nlm
>>>> Internet Explorer 6.0.2800.1106 with all security patches up to date
>>>> I tried http://(url):8080/index.jsp%20 and
>>>> https://(url)/tomcat/admin/index.jsp%20
>>>>
>>>> Hopefully this mail gets through; I haven't been seeing my emails
>>>>
>>>
>> show
>>
>>
>>>> up on tomcat-user for some reason (I un/resubscribed today...)
>>>>
>>>> It would be really good to get to the bottom of this!
>>>>
>>>> Jeff Tulley (jtulley@novell.com)
>>>> (801)861-5322
>>>> Novell, Inc., The Leading Provider of Net Business Solutions
>>>> http://www.novell.com
>>>>
>>>>
>>>>
>>>>>>> ccox@cincom.com 8/12/03 6:02:55 AM >>>
>>>>>>>
>>>>>>>
>>>>>>
>>>> can you turn on debugging for the default servlet(conf/web.xml) and
>>>> also
>>>> turn on the requestdumpervalve(server.xml) and post the log.
>>>>
>>>>
>>>
>>
>>
>
>
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: tomcat-dev-unsubscribe@jakarta.apache.org
> For additional commands, e-mail: tomcat-dev-help@jakarta.apache.org
>
>
--
Sincerely,
Reshat.
-------------------------------------------------------------------------------------------
If you see my certificate with this message, you should be able to send me encrypted e-mail.
Please consult your e-mail client for details if you would like to do that.
Re: Fwd: Re: security hole on windows tomcat?
Posted by Reshat Sabiq <sa...@purdue.edu>.
If the bug was caused by adding %20 to a page/folder in URL, then i
didn't reproduce it in Tomcat 5. I got 404 (the only bad thing is that
404's don't appear to be customizable with error-page directives in
web.xml).
What would be a good list to watch for these kinds of bugs in Tomcat?
Thanks.
Paul Sundling wrote:
> Yes, adding
>
> -Dsun.io.useCanonCaches=false
>
> to the tomcat seemed to fix the security hole I discovered on my
> 4.1.24 tomcat on Windows XP using JDK 1.4.2. Great job finding a
> solution. It's a testament to open source and cooperation.
> Fortunately it's JSP source it's showing and people should have
> anything worth seeing in their servlets or EJBs anyway. :)
> Paul Sundling
>
>
> Jeff Tulley wrote:
>
>> I just wanted to make sure you saw this -- Jeanfrancois made the
>> connection that this issue has a known workaround, so you don't have to
>> backrev your JVM if you don't want to.
>>
>> I tried this on Windows XP and NetWare and it worked in both places...
>>
>> Jeff Tulley (jtulley@novell.com)
>> (801)861-5322
>> Novell, Inc., The Leading Provider of Net Business Solutions
>> http://www.novell.com
>>
>>
>>
>>>>> jfarcand@apache.org 8/12/03 7:08:50 PM >>>
>>>>>
>>>>
>> Sorry I've just realize this thread may be related to bugtraq #4895132
>> (thanks to Jeff for the wake up mail on tomcat-dev ;-) ). The
>> workaround is to add the following property when starting Tomcat:
>>
>> -Dsun.io.useCanonCaches=false
>>
>> Can someone try it and let me know if it change something. If this is
>> not working, then point me to a very simple test case and I will file a
>>
>> new bugtraq bug.
>>
>> -- Jeanfrancois
>>
>>
>> Eric J. Pinnell wrote:
>>
>>
>>
>>> I think at this point this might be a worthwile canidate for Sun's
>>> bugparade. At least get it on their radars (if they don't know about
>>>
>>
>> it
>>
>>
>>> already). It's interesting that the bug doesn't show up in Tomcat
>>>
>>
>> 4.1.27.
>>
>>
>>> When 1.4.2 was released 4.1.24 was the latest stable build.
>>>
>>> Regardless the JDK/appserver/whatever should never puke it's guts and
>>>
>>
>> spit
>>
>>
>>> out the source code when it gets a request it doesn't know how to
>>>
>>
>> deal
>>
>>
>>> with. Upon failure it should result in some kind of error. Sun
>>>
>>
>> might
>>
>>
>>> care about this...
>>>
>>> -e
>>>
>>> On Tue, 12 Aug 2003, Jeff Tulley wrote:
>>>
>>>
>>>
>>>
>>>
>>>> It is highly possible that this is dependent on the JVM you have
>>>> installed. I actually finally WAS able to see this on Windows XP,
>>>>
>>>
>> but
>>
>>
>>>> only if Tomcat was running on JVM 1.4.2. The problem did NOT happen
>>>> with 1.4.1. Of course, JVM version is the one item I left off of my
>>>> "poll" in my email below. :)
>>>>
>>>> I'm trying to verify this on other OS's and track down what the
>>>>
>>>
>> actual
>>
>>
>>>> problem is.
>>>>
>>>> But, if you run Tomcat on JVM 1.4.2, verify if you have this
>>>>
>>>
>> problem.
>>
>>
>>>> Jeff Tulley (jtulley@novell.com)
>>>> (801)861-5322
>>>> Novell, Inc., The Leading Provider of Net Business Solutions
>>>> http://www.novell.com
>>>>
>>>>
>>>>
>>>>>>> mpnix@optusnet.com.au 8/12/03 4:10:53 PM >>>
>>>>>>>
>>>>>>>
>>>>>>
>>>> Tomcat 4.0.6 on Win2K via direct connection to Tomcat on localhost
>>>>
>>>
>> via
>>
>>
>>>> either port 8080 or port 80 - pages return fine without the %20
>>>> suffix,
>>>> always return http 404 with the suffix.
>>>>
>>>> Murray
>>>> -----Original Message-----
>>>> From: Jeff Tulley [mailto:JTULLEY@novell.com] Sent: Wednesday, 13
>>>> August 2003 02:41
>>>> To: tomcat-user@jakarta.apache.org Subject: RE: security hole on
>>>> windows tomcat?
>>>>
>>>>
>>>> So this issue is confusing. It seems that indeed there IS an issue,
>>>> though most cannot see a problem.
>>>> Talking to some people off-list, it seems that some think it is a
>>>>
>>>
>> JK2
>>
>>
>>>> /
>>>> workers2.properties issue. But I'm pretty sure that others have
>>>>
>>>
>> seen
>>
>>
>>>> this going directly to port 8080.
>>>> We probably need to take a quick poll:
>>>>
>>>> If you have seen this security problem of being able to view JSP
>>>> source, in what scenario(s)?
>>>>
>>>> Tomcat version
>>>> OS version
>>>> Directly to Tomcat ("8080") or through Apache - JK or JK2?
>>>> (If you've seen the problem, please include your workers or
>>>> workers2.properties file, with a .txt extension)
>>>> Browser version(s)
>>>> url's where this was seen or not seen
>>>>
>>>> If you have seen this in multiple scenarios, and not in others,
>>>>
>>>
>> please
>>
>>
>>>> list each separately.
>>>>
>>>>
>>>> I have NOT seen it in the following scenarios:
>>>>
>>>> Tomcat 4.1.18, 4.1.24, 4.1.26, 4.1.27
>>>> Windows 2000 5.00.2195 Service Pack 4
>>>> Directly to port 8080
>>>> Internet Explorer 6.0.2800.1106 with all security patches up to date
>>>> I tried http://(url):8080/index.jsp%20
>>>> Tomcat 4.1.18, 4.1.24, 4.1.26, fairly standard distributions (only
>>>> adding one JNDIRealm beyond the default config)
>>>> Novell NetWare 6.5
>>>> Directly to port 8080, and through Apache - mod_jk.nlm
>>>> Internet Explorer 6.0.2800.1106 with all security patches up to date
>>>> I tried http://(url):8080/index.jsp%20 and
>>>> https://(url)/tomcat/admin/index.jsp%20
>>>>
>>>> Hopefully this mail gets through; I haven't been seeing my emails
>>>>
>>>
>> show
>>
>>
>>>> up on tomcat-user for some reason (I un/resubscribed today...)
>>>>
>>>> It would be really good to get to the bottom of this!
>>>>
>>>> Jeff Tulley (jtulley@novell.com)
>>>> (801)861-5322
>>>> Novell, Inc., The Leading Provider of Net Business Solutions
>>>> http://www.novell.com
>>>>
>>>>
>>>>
>>>>>>> ccox@cincom.com 8/12/03 6:02:55 AM >>>
>>>>>>>
>>>>>>>
>>>>>>
>>>> can you turn on debugging for the default servlet(conf/web.xml) and
>>>> also
>>>> turn on the requestdumpervalve(server.xml) and post the log.
>>>>
>>>>
>>>
>>
>>
>
>
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: tomcat-dev-unsubscribe@jakarta.apache.org
> For additional commands, e-mail: tomcat-dev-help@jakarta.apache.org
>
>
--
Sincerely,
Reshat.
-------------------------------------------------------------------------------------------
If you see my certificate with this message, you should be able to send me encrypted e-mail.
Please consult your e-mail client for details if you would like to do that.