Thanks Bill. I found the details of the bug fix: Bug Fix - http://marc.info/?l=tomcat-dev&m=101055775717102&w=2 Related email - http://marc.info/?l=tomcat-dev&m=101055563114160&w=2 http://marc.info/?l=tomcat-dev&m=117236875932374&w=2 states Affected versions to be 3.0, 3.1-3.1.1, 3.2-3.2.4, 3.3
But I find JavaGeneratorTool.java file(where I believe the fix was made) does not exist before 3.3.X. Not sure if there is a Windows / JRE version implication in reproducing the bug. I even tried with JRE 1.3.0_01. We still get a 404 and Tomcat doesn't seem to hang. Please let me know if anyone knows the conditions under which the bug is reproducible. Our product uses Tomcat 3.2 and since all external documentation indicate the bug is present in Tomcat versions prior to 3.3.1a, we don't have any official documentation to state the bug is not really there. Regards, Mamatha -----Original Message----- From: news [mailto:[EMAIL PROTECTED] On Behalf Of Bill Barker Sent: Wednesday, February 20, 2008 1:52 PM To: dev@tomcat.apache.org Subject: Re: Tomcat 3.2.x problem with MS-DOS device names I seem to recall that this was fixed in 3.2.4, but I can't be sure since I mostly passed over those commit messages at the time. It was the reason to produce 3.3.1a, so is also fixed in 3.3.2 (easier upgrade path). However, it hangs connections pretty consistantly on affected systems, so if you get a 404 (what I would expect from TC5+), then the bug isn't really there. "Mamatha Rao (mamtarao)" <[EMAIL PROTECTED]> wrote in message news:[EMAIL PROTECTED] ... Hi, Our application used Tomcat 3.2 and Nessus scan reported the following CVE against it http://nvd.nist.gov/nvd.cfm?cvename=CVE-2003-0045 <BLOCKED::http://nvd.nist.gov/nvd.cfm?cvename=CVE-2003-0045> Tomcat release notes suggest fixing defect in 3.3.1a and later. We moved to Tomcat 5.5 and still saw Nessus reporting the same vulnerability. The Nessus scan may not be accurate since we ensured that Tomcat did not actually freeze after the attack. However, we are now stuck in verifying the vulnerability existed in Tomcat 3.2. Have tried testing with a sample servlet - it returns a 404 Not Found error on requests like http://[ip <BLOCKED::http://[ip/> addr]:8080/test/aux.jsp. Traces show something like java.io.IOException: Bad pathname at java.io.WinNTFileSystem.canonicalize0(Native Method) at java.io.Win32FileSystem.canonicalize(Win32FileSystem.java:354) at java.io.File.getCanonicalPath(File.java:513) at org.apache.tomcat.util.FileUtil.safePath(FileUtil.java:184) at org.apache.tomcat.core.Context.getRealPath(Context.java:797) at org.apache.tomcat.facade.ServletContextFacade.getRealPath(ServletCont extFacade.java:136) at org.apache.jasper.JspEngineContext.getRealPath(JspEngineContext.java: 359) .... 2008-02-19 10:18:05 - Ctx( /test ): 404 R( /test + /aux.jsp + null) JSP file not found 2008-02-19 10:18:05 - Ctx( /test ): Handler tomcat.notFoundHandler(null/null) to mcat.notFoundHandler on such requests. And even with limiting the number of threads, Tomcat does not freeze. And thread dumps dont indicate anything wrong. Have tried it both on Windows 2000 server and Windows XP. Is there any dependency on Windows versions? http://nvd.nist.gov/nvd.cfm?cvename=CVE-2003-0045 <BLOCKED::http://nvd.nist.gov/nvd.cfm?cvename=CVE-2003-0045> seems to suggest it occurs in certain Windows systems while http://xforce.iss.net/xforce/xfdb/12102 <BLOCKED::http://xforce.iss.net/xforce/xfdb/12102> says it occurs in all versions of Windows. http://marc.info/?l=tomcat-dev&m=101055029706766&w=2 <http://marc.info/?l=tomcat-dev&m=101055029706766&w=2> - This mail thread is refering to some similar/same(?) bug and suggests even Windows NT, 2000 have a problem but may be Tomcat 3.2.4 doesnt show the problem. Does anyone remember if this vulnerability can be triggered in Tomcat 3.2 and how? Any pointers to the bug fix in subversion would also help. Regards Mamatha --------------------------------------------------------------------- To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED] --------------------------------------------------------------------- To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
