svn commit: r587013 - /tomcat/current/tc4.1.x/STATUS

[rjung]

Author: rjung
Date: Sun Oct 21 23:59:47 2007
New Revision: 587013

URL: http://svn.apache.org/viewvc?rev=587013&view=rev
Log:
Propose patch to expand system properties
in server.xml.

Modified:
tomcat/current/tc4.1.x/STATUS

Modified: tomcat/current/tc4.1.x/STATUS
URL: 
http://svn.apache.org/viewvc/tomcat/current/tc4.1.x/STATUS?rev=587013&r1=587012&r2=587013&view=diff
==
--- tomcat/current/tc4.1.x/STATUS (original)
+++ tomcat/current/tc4.1.x/STATUS Sun Oct 21 23:59:47 2007
@@ -35,3 +35,10 @@
   http://people.apache.org/~markt/patches/2007-10-20-webdav.patch
   +1: markt
   -1:
+
+* Add feature to use system properties in server.xml.
+  TC 5.0/5.5/6.0 already can do this, and since commons-digester
+  in TC 4.1 is recent enough, it's easy for TC 4.1 to.
+  
http://people.apache.org/~rjung/patches/replace_system_properties_20071018a.patch
+  +1: rjung
+  -1:



-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]

Re: [Fwd: [Security] - **Updated** Important vulnerability disclosed in Apache Tomcat webdav servlet]

[jean-frederic clere]

jkew wrote:
> Mark Thomas wrote:
>> William L. Thomson Jr. wrote:
>>  
>>> I take it down streams should run with the first patches to work around
>>> this vulnerability till next release. I already applied the one liner,
>>> kinda glad I did not apply the other last night ;) Please advise,
>>> thanks.
>>> 
>>
>> You need a version of the second patch for a complete fix. If you want
>> logging - apply my version, if you don't - apply Remy's. Both fix the
>> problem, just in slightly different ways.
>>
>>   
> 
> I've been using Mark's patch, which I personally prefer right now. I'll
> experiment with Remy's patch on Monday, but I have a slightly tangential
> question:
> 
> Q. Where should I put, and how should I build a unit test for the webdav
> issue? I noticed that Jean-Frederic created a great unit test within
> /test for the cookie issue, but I don't believe his patch was ever
> committed. Is there a formal unit test framework for these issues?

No yet but I think we should have tests for nearly everything.

Cheers

Jean-Frederic

> 
> My existing test for the webdav issue is just a war file, but I'd like
> something semi-permanent and manageable. I'm a little ignorant of of the
> history here, so forgive me if I'm a little lost.
>> We'll have to wait and see which way the voting goes for which patch
>> gets incorporated into the code base.
>>
>> Mark
>>
>> -
>> 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]
> 
> 


-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]

svn commit: r587018 - /tomcat/tc6.0.x/trunk/STATUS

[jfclere]

Author: jfclere
Date: Mon Oct 22 00:18:49 2007
New Revision: 587018

URL: http://svn.apache.org/viewvc?rev=587018&view=rev
Log:
Add the Cookies tests patch.

Modified:
tomcat/tc6.0.x/trunk/STATUS

Modified: tomcat/tc6.0.x/trunk/STATUS
URL: 
http://svn.apache.org/viewvc/tomcat/tc6.0.x/trunk/STATUS?rev=587018&r1=587017&r2=587018&view=diff
==
--- tomcat/tc6.0.x/trunk/STATUS (original)
+++ tomcat/tc6.0.x/trunk/STATUS Mon Oct 22 00:18:49 2007
@@ -85,3 +85,6 @@
   +1: billbarker
   -1:
 
+* Tests for unit tests for the cookie issues. 
http://people.apache.org/~jfclere/patches/CookiesTest.patch
+  +1:
+  -1:



-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]

svn commit: r587043 - /tomcat/tc6.0.x/trunk/STATUS

[jfclere]

Author: jfclere
Date: Mon Oct 22 02:05:37 2007
New Revision: 587043

URL: http://svn.apache.org/viewvc?rev=587043&view=rev
Log:
Propose a better patch for IcedTea support. 

Modified:
tomcat/tc6.0.x/trunk/STATUS

Modified: tomcat/tc6.0.x/trunk/STATUS
URL: 
http://svn.apache.org/viewvc/tomcat/tc6.0.x/trunk/STATUS?rev=587043&r1=587042&r2=587043&view=diff
==
--- tomcat/tc6.0.x/trunk/STATUS (original)
+++ tomcat/tc6.0.x/trunk/STATUS Mon Oct 22 02:05:37 2007
@@ -52,7 +52,7 @@
  if [ -z "$JAVA_HOME" -a "$1" = "debug" ]; then
 
   +1: 
-  -1:
+  -1: jfclere. I have proposed a "better" patch below.
0: yoavs,rjung
Comment by rjung: Maybe switching "then" and "else" cases by using "-x" 
instead of "! -x".
  This way the error exit stays the last case which seems 
more natural.
@@ -86,5 +86,9 @@
   -1:
 
 * Tests for unit tests for the cookie issues. 
http://people.apache.org/~jfclere/patches/CookiesTest.patch
+  +1:
+  -1:
+
+* Guess java location from the PATH environment. 
http://people.apache.org/~jfclere/patches/setclasspath.sh.patch
   +1:
   -1:



-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]

svn commit: r587045 - /tomcat/tc6.0.x/trunk/STATUS

[jfclere]

Author: jfclere
Date: Mon Oct 22 02:07:39 2007
New Revision: 587045

URL: http://svn.apache.org/viewvc?rev=587045&view=rev
Log:
It also improve the fix for 37284.

Modified:
tomcat/tc6.0.x/trunk/STATUS

Modified: tomcat/tc6.0.x/trunk/STATUS
URL: 
http://svn.apache.org/viewvc/tomcat/tc6.0.x/trunk/STATUS?rev=587045&r1=587044&r2=587045&view=diff
==
--- tomcat/tc6.0.x/trunk/STATUS (original)
+++ tomcat/tc6.0.x/trunk/STATUS Mon Oct 22 02:07:39 2007
@@ -90,5 +90,6 @@
   -1:
 
 * Guess java location from the PATH environment. 
http://people.apache.org/~jfclere/patches/setclasspath.sh.patch
+  And improve fix for 37284.
   +1:
   -1:



-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]

DO NOT REPLY [Bug 43671] New: - Unclear Contract between Entity expansion and DOM parser validation cause OWASP A2 in WebDAV Servlet

[bugzilla]

DO NOT REPLY TO THIS EMAIL, BUT PLEASE POST YOUR BUG·
RELATED COMMENTS THROUGH THE WEB INTERFACE AVAILABLE AT
.
ANY REPLY MADE TO THIS MESSAGE WILL NOT BE COLLECTED AND·
INSERTED IN THE BUG DATABASE.

http://issues.apache.org/bugzilla/show_bug.cgi?id=43671

   Summary: Unclear Contract between Entity expansion and DOM parser
validation cause OWASP A2 in WebDAV  Servlet
   Product: Tomcat 5
   Version: 5.5.24
  Platform: All
OS/Version: All
Status: NEW
  Severity: major
  Priority: P2
 Component: Servlets:WebDAV
AssignedTo: [EMAIL PROTECTED]
ReportedBy: [EMAIL PROTECTED]


DESCRIPTION:

Tomcat allows unauthorized users reading arbitrary files
from the host file system by misusing the entity expansion
feature of the DOM parser. 

It seems that

documentBuilderFactory.setExpandEntityReferences(false);

has no atomic effect, instead it depends on other (undocumented) settings.
There are also (although antique) references on the web
supporting this assumption. They say XML validation overrides
disabling of entity expansion.

(Quote: http://www.cafeconleche.org/books/xmljava/chapters/ch09s06.html)

"""Expand Entity References

The following two methods determine whether the parsers produced by this factory
expand entity references.
public boolean isExpandEntityReferences();
public void setExpandEntityReferences(boolean expandEntityReferences);

The default is true. If a parser is validating, then this it will expand entity
references, even if this feature is set to false. That is, the validation
feature overrides the expand entity references feature."""
(/Quote)


http://mail-archives.apache.org/mod_mbox/xerces-j-users/200410.mbox/[EMAIL 
PROTECTED]

The JDK I used was also not overaged:

java version "1.5.0_13"
Java(TM) 2 Runtime Environment, Standard Edition (build 1.5.0_13-b05)
Java HotSpot(TM) Server VM (build 1.5.0_13-b05, mixed mode)

EFFECT:

Unauthenticated users get file contents presented when webdav write access is
enabled, even when 
documentBuilderFactory.setExpandEntityReferences(false);
is set. 

[EMAIL PROTECTED] 20071014webdavexp]$ perl cve-2007-5461-exploit.pl 127.0.0.1
/webdav /etc/passwd
Apache Tomcat Remote File Disclosure Zeroday Xploit
kcdarookie aka eliteb0y / 2007
Launching Remote Exploit...
HTTP/1.1 200 OK
Server: Apache-Coyote/1.1
Content-Type: text/xml;charset=UTF-8
Content-Length: 2163
Date: Fri, 19 Oct 2007 09:47:28 GMT




Infinity



root:x:0:0:root:/root:/bin/bash
bin:x:1:1:bin:/bin:/sbin/nologin
daemon:x:2:2:daemon:/sbin:/sbi


PATCH PROPOSAL:

The abstract DocumentBuilder offers a method

public abstract void setEntityResolver(EntityResolver er)

You can override this with a custom resolver such as:

  documentBuilder = documentBuilderFactory.newDocumentBuilder();
  documentBuilder.setEntityResolver(new MyResolver());


The following PoC implementation shows the protection effect below:

 private class MyResolver implements EntityResolver {
   public InputSource resolveEntity (String publicId, String systemId)
   {
System.err.println("pub:"+publicId);
System.err.println("sys:"+systemId);
if (systemId.startsWith("file:")) {
System.err.println("attack");
return new InputSource("");
}   
return null;
   }

This will catch file references to be expanded, and should be
extended to http:// and other external stuff for production purpose.
And there may be other side cases that are needed to observe.
The return value 'hubbabubba' may also need some nicer value :)

Result:

Oct 19, 2007 1:01:15 PM org.apache.catalina.core.ApplicationContext log
pub:null
sys:file:///etc/passwd
attack
Oct 19, 2007 1:01:15 PM org.apache.catalina.core.StandardWrapperValve invoke
SEVERE: Servlet.service() for servlet webdav threw exception
java.lang.NullPointerException
at 
org.apache.catalina.servlets.WebdavServlet.doLock(WebdavServlet.java:966)

SUMMARY: 
It has been observed, that the unclear Contract between Entity expansion and DOM
parser validation affects the security of the WebDAV servlet when write access
is enabled. A PoC patch has been appended to show a potential way to mitigate  
the issue by blocking unwanted external entities which creates a Injection Flaw
vulnerability (OWASP A2) .

-- 
Configure bugmail: http://issues.apache.org/bugzilla/userprefs.cgi?tab=email
--- You are receiving this mail because: ---
You are the assignee for the bug, or are watching the assignee.

-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]

DO NOT REPLY [Bug 43671] - Unclear Contract between Entity expansion and DOM parser validation cause OWASP A2 in WebDAV Servlet

[bugzilla]

DO NOT REPLY TO THIS EMAIL, BUT PLEASE POST YOUR BUG·
RELATED COMMENTS THROUGH THE WEB INTERFACE AVAILABLE AT
.
ANY REPLY MADE TO THIS MESSAGE WILL NOT BE COLLECTED AND·
INSERTED IN THE BUG DATABASE.

http://issues.apache.org/bugzilla/show_bug.cgi?id=43671





--- Additional Comments From [EMAIL PROTECTED]  2007-10-22 02:59 ---
Created an attachment (id=21018)
 --> (http://issues.apache.org/bugzilla/attachment.cgi?id=21018&action=view)
Testcase taken from full-disclosure mailing list

Try with the following command line: 

perl cve-2007-5461-exploit.pl 127.0.0.1 /webdav /etc/passwd 

-- 
Configure bugmail: http://issues.apache.org/bugzilla/userprefs.cgi?tab=email
--- You are receiving this mail because: ---
You are the assignee for the bug, or are watching the assignee.

-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]

DO NOT REPLY [Bug 43671] - Unclear Contract between Entity expansion and DOM parser validation cause OWASP A2 in WebDAV Servlet

[bugzilla]

DO NOT REPLY TO THIS EMAIL, BUT PLEASE POST YOUR BUG·
RELATED COMMENTS THROUGH THE WEB INTERFACE AVAILABLE AT
.
ANY REPLY MADE TO THIS MESSAGE WILL NOT BE COLLECTED AND·
INSERTED IN THE BUG DATABASE.

http://issues.apache.org/bugzilla/show_bug.cgi?id=43671





--- Additional Comments From [EMAIL PROTECTED]  2007-10-22 03:16 ---
Created an attachment (id=21019)
 --> (http://issues.apache.org/bugzilla/attachment.cgi?id=21019&action=view)
Code fragment showing how to intercept injected entities

The attached (ugly) code fragment shows how to intercept the process of 
entity expansion by detecting the injected strings.
As an example it intercepts entities with a 
"file:" prefix and posts it to stderr.  

As the comitter is not really an expert
of the WEBDAV semantics this patch draft may need some
brush up to be production ready. 

When used with Webdav write access enabled and the 
perl script with 

perl cve-2007-5461-exploit.pl 127.0.0.1 /webdav /etc/passwd 

the entity expansion and injection attack is detected an the following output
is posted to stderr: 

Oct 19, 2007 1:01:15 PM org.apache.catalina.core.ApplicationContext log
pub:null
sys:file:///etc/passwd
attack
Oct 19, 2007 1:01:15 PM org.apache.catalina.core.StandardWrapperValve invoke
SEVERE: Servlet.service() for servlet webdav threw exception
java.lang.NullPointerException
at
org.apache.catalina.servlets.WebdavServlet.doLock(WebdavServlet.java:966)


-- 
Configure bugmail: http://issues.apache.org/bugzilla/userprefs.cgi?tab=email
--- You are receiving this mail because: ---
You are the assignee for the bug, or are watching the assignee.

-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]

svn commit: r587062 - /tomcat/tc6.0.x/trunk/STATUS

[remm]

Author: remm
Date: Mon Oct 22 04:38:28 2007
New Revision: 587062

URL: http://svn.apache.org/viewvc?rev=587062&view=rev
Log:
- Vote.

Modified:
tomcat/tc6.0.x/trunk/STATUS

Modified: tomcat/tc6.0.x/trunk/STATUS
URL: 
http://svn.apache.org/viewvc/tomcat/tc6.0.x/trunk/STATUS?rev=587062&r1=587061&r2=587062&view=diff
==
--- tomcat/tc6.0.x/trunk/STATUS (original)
+++ tomcat/tc6.0.x/trunk/STATUS Mon Oct 22 04:38:28 2007
@@ -25,43 +25,11 @@
 PATCHES PROPOSED TO BACKPORT:
   [ New proposals should be added at the end of the list ]
 
-* IcedTea support. Upcoming Linux distributions will package a (working) open 
source JRE,
-  available in /usr. As a result, it could now be possible to use a 
"/usr/bin/java" binary
-  if one is present and expect results. [tested on Fedora 8 test 3]
-
-Index: 
/home/remm/Work/eclipse/jbossweb-2.1.x/apache-tomcat-6.0.x/bin/setclasspath.sh
-===
 
/home/remm/Work/eclipse/jbossweb-2.1.x/apache-tomcat-6.0.x/bin/setclasspath.sh  
   (revision 586293)
-+++ 
/home/remm/Work/eclipse/jbossweb-2.1.x/apache-tomcat-6.0.x/bin/setclasspath.sh  
   (working copy)
-@@ -30,9 +30,13 @@
-   if $darwin && [ -d 
"/System/Library/Frameworks/JavaVM.framework/Versions/1.5/Home" ]; then
- export 
JAVA_HOME="/System/Library/Frameworks/JavaVM.framework/Versions/1.5/Home"
-   else
--echo "Neither the JAVA_HOME nor the JRE_HOME environment variable is 
defined"
--echo "At least one of these environment variable is needed to run this 
program"
--exit 1
-+if [ -x /usr/bin/java ]; then
-+  JRE_HOME=/usr
-+else
-+  echo "Neither the JAVA_HOME nor the JRE_HOME environment variable is 
defined"
-+  echo "At least one of these environment variable is needed to run this 
program"
-+  exit 1
-+fi
-   fi
- fi
- if [ -z "$JAVA_HOME" -a "$1" = "debug" ]; then
-
-  +1: 
-  -1: jfclere. I have proposed a "better" patch below.
-   0: yoavs,rjung
-   Comment by rjung: Maybe switching "then" and "else" cases by using "-x" 
instead of "! -x".
- This way the error exit stays the last case which seems 
more natural.
-
 * Fix MD5 files for distribution
   http://issues.apache.org/bugzilla/attachment.cgi?id=21009&action=view
   +1: fhanik,funkman, markt
   -1: 
-  
+
 * Final fix for http://issues.apache.org/bugzilla/show_bug.cgi?id=43653
   Fixes the 100 Continue response, that got reversed through byte buffer 
manipulation
   last patch before tag, promise :)
@@ -72,7 +40,7 @@
 * Improve fix for webdav vulnerability to workaround what looks like a parser
   bug
   http://people.apache.org/~markt/patches/2007-10-20-webdav.patch
-  +1: markt,fhanik
+  +1: markt,fhanik, remm
   -1:
 
 * Fix possible DoS condition for the experimental NIO/AJP module (reported by 
William Leung via email)
@@ -83,7 +51,7 @@
 * Fix problem on a Forward when the outer most wrapper isn't a 
HttpServletRequest/ResponseWrapper.
   http://issues.apache.org/bugzilla/show_bug.cgi?id=43668
   +1: billbarker
-  -1:
+  -1: remm (I don't feel comfortable including this sort of fix right before a 
release)
 
 * Tests for unit tests for the cookie issues. 
http://people.apache.org/~jfclere/patches/CookiesTest.patch
   +1:



-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]

DO NOT REPLY [Bug 43671] - Unclear Contract between Entity expansion and DOM parser validation cause OWASP A2 in WebDAV Servlet

[bugzilla]

DO NOT REPLY TO THIS EMAIL, BUT PLEASE POST YOUR BUG·
RELATED COMMENTS THROUGH THE WEB INTERFACE AVAILABLE AT
.
ANY REPLY MADE TO THIS MESSAGE WILL NOT BE COLLECTED AND·
INSERTED IN THE BUG DATABASE.

http://issues.apache.org/bugzilla/show_bug.cgi?id=43671





--- Additional Comments From [EMAIL PROTECTED]  2007-10-22 05:25 ---
(In reply to comment #0)
> If a parser is validating, then this it will expand entity
> references, even if this feature is set to false. That is, the validation
> feature overrides the expand entity references feature.

This doesn't appear to be related to the validation setting which defaults to
false and isn't changed from the default in this case. It appears to be that the
settings in documentBuilderFactory are not passed through to the underlying 
parser.

The proposed patch for this, based on your suggestion, is here:
http://people.apache.org/~markt/patches/2007-10-20-webdav.patch

-- 
Configure bugmail: http://issues.apache.org/bugzilla/userprefs.cgi?tab=email
--- You are receiving this mail because: ---
You are the assignee for the bug, or are watching the assignee.

-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]

svn commit: r587082 - in /tomcat/tc6.0.x/trunk: STATUS java/org/apache/catalina/servlets/LocalStrings.properties java/org/apache/catalina/servlets/WebdavServlet.java webapps/docs/changelog.xml

[markt]

Author: markt
Date: Mon Oct 22 06:19:05 2007
New Revision: 587082

URL: http://svn.apache.org/viewvc?rev=587082&view=rev
Log:
Improve patch for WebDAV issue.

Modified:
tomcat/tc6.0.x/trunk/STATUS

tomcat/tc6.0.x/trunk/java/org/apache/catalina/servlets/LocalStrings.properties
tomcat/tc6.0.x/trunk/java/org/apache/catalina/servlets/WebdavServlet.java
tomcat/tc6.0.x/trunk/webapps/docs/changelog.xml

Modified: tomcat/tc6.0.x/trunk/STATUS
URL: 
http://svn.apache.org/viewvc/tomcat/tc6.0.x/trunk/STATUS?rev=587082&r1=587081&r2=587082&view=diff
==
--- tomcat/tc6.0.x/trunk/STATUS (original)
+++ tomcat/tc6.0.x/trunk/STATUS Mon Oct 22 06:19:05 2007
@@ -37,12 +37,6 @@
   +1: fhanik
   -1: 
 
-* Improve fix for webdav vulnerability to workaround what looks like a parser
-  bug
-  http://people.apache.org/~markt/patches/2007-10-20-webdav.patch
-  +1: markt,fhanik, remm
-  -1:
-
 * Fix possible DoS condition for the experimental NIO/AJP module (reported by 
William Leung via email)
   http://issues.apache.org/bugzilla/show_bug.cgi?id=43621
   +1: billbarker,fhanik

Modified: 
tomcat/tc6.0.x/trunk/java/org/apache/catalina/servlets/LocalStrings.properties
URL: 
http://svn.apache.org/viewvc/tomcat/tc6.0.x/trunk/java/org/apache/catalina/servlets/LocalStrings.properties?rev=587082&r1=587081&r2=587082&view=diff
==
--- 
tomcat/tc6.0.x/trunk/java/org/apache/catalina/servlets/LocalStrings.properties 
(original)
+++ 
tomcat/tc6.0.x/trunk/java/org/apache/catalina/servlets/LocalStrings.properties 
Mon Oct 22 06:19:05 2007
@@ -25,6 +25,7 @@
 invokerServlet.notNamed=Cannot call invoker servlet with a named dispatcher
 invokerServlet.noWrapper=Container has not called setWrapper() for this servlet
 webdavservlet.jaxpfailed=JAXP initialization failed
+webdavservlet.enternalEntityIgnored=The request included a reference to an 
external entity with PublicID {0} and SystemID {1} which was ignored
 directory.filename=Filename
 directory.lastModified=Last Modified
 directory.parent=Up To {0}

Modified: 
tomcat/tc6.0.x/trunk/java/org/apache/catalina/servlets/WebdavServlet.java
URL: 
http://svn.apache.org/viewvc/tomcat/tc6.0.x/trunk/java/org/apache/catalina/servlets/WebdavServlet.java?rev=587082&r1=587081&r2=587082&view=diff
==
--- tomcat/tc6.0.x/trunk/java/org/apache/catalina/servlets/WebdavServlet.java 
(original)
+++ tomcat/tc6.0.x/trunk/java/org/apache/catalina/servlets/WebdavServlet.java 
Mon Oct 22 06:19:05 2007
@@ -20,6 +20,7 @@
 
 
 import java.io.IOException;
+import java.io.StringReader;
 import java.io.StringWriter;
 import java.io.Writer;
 import java.security.MessageDigest;
@@ -36,6 +37,7 @@
 import javax.naming.NamingEnumeration;
 import javax.naming.NamingException;
 import javax.naming.directory.DirContext;
+import javax.servlet.ServletContext;
 import javax.servlet.ServletException;
 import javax.servlet.UnavailableException;
 import javax.servlet.http.HttpServletRequest;
@@ -57,6 +59,7 @@
 import org.w3c.dom.Element;
 import org.w3c.dom.Node;
 import org.w3c.dom.NodeList;
+import org.xml.sax.EntityResolver;
 import org.xml.sax.InputSource;
 import org.xml.sax.SAXException;
 
@@ -245,6 +248,8 @@
 documentBuilderFactory.setNamespaceAware(true);
 documentBuilderFactory.setExpandEntityReferences(false);
 documentBuilder = documentBuilderFactory.newDocumentBuilder();
+documentBuilder.setEntityResolver(
+new WebdavResolver(this.getServletContext()));
 } catch(ParserConfigurationException e) {
 throw new ServletException
 (sm.getString("webdavservlet.jaxpfailed"));
@@ -2779,6 +2784,26 @@
 }
 
 
+// - WebdavResolver Inner Class
+/**
+ * Work around for XML parsers that don't fully respect
+ * [EMAIL PROTECTED] 
DocumentBuilderFactory#setExpandEntityReferences(false)}. External
+ * references are filtered out for security reasons. See CVE-2007-5461.
+ */
+private class WebdavResolver implements EntityResolver {
+private ServletContext context;
+
+public WebdavResolver(ServletContext theContext) {
+context = theContext;
+}
+ 
+public InputSource resolveEntity (String publicId, String systemId) {
+context.log(sm.getString("webdavservlet.enternalEntityIgnored",
+publicId, systemId));
+return new InputSource(
+new StringReader("Ignored external entity"));
+}
+}
 };
 
 
@@ -3100,4 +3125,5 @@
 }
 
 };
+
 

Modified: tomcat/tc6.0.x/trunk/webapps/docs/changelog.xml
URL: 
http://svn.apache.org/viewvc/tomcat/tc6.0.x/trunk/webapps/docs/changelog.xml?rev=587082&r1=587081&r2=587082&view=diff
===

DO NOT REPLY [Bug 43668] - ApplicationDispatcher.doForward for non-HTTP request is always NULL

[bugzilla]

DO NOT REPLY TO THIS EMAIL, BUT PLEASE POST YOUR BUG·
RELATED COMMENTS THROUGH THE WEB INTERFACE AVAILABLE AT
.
ANY REPLY MADE TO THIS MESSAGE WILL NOT BE COLLECTED AND·
INSERTED IN THE BUG DATABASE.

http://issues.apache.org/bugzilla/show_bug.cgi?id=43668





--- Additional Comments From [EMAIL PROTECTED]  2007-10-22 06:36 ---
39417: ApplicationDispatcher.unwrapRequest() should not assume 
servletRequestWrapper
http://issues.apache.org/bugzilla/show_bug.cgi?id=39417

What do you mean, is it that a bug 39417 is even further away to be fixed?
I made a quick test and posted a solution I used, a simple is-instanceof check
and bail out. Fix is posted at the end of 39417 report.



-- 
Configure bugmail: http://issues.apache.org/bugzilla/userprefs.cgi?tab=email
--- You are receiving this mail because: ---
You are the assignee for the bug, or are watching the assignee.

-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]

svn commit: r587115 - in /tomcat/tc6.0.x/trunk: STATUS dist.xml webapps/docs/changelog.xml

[fhanik]

Author: fhanik
Date: Mon Oct 22 07:46:04 2007
New Revision: 587115

URL: http://svn.apache.org/viewvc?rev=587115&view=rev
Log:
Add in MD5 fix

Modified:
tomcat/tc6.0.x/trunk/STATUS
tomcat/tc6.0.x/trunk/dist.xml
tomcat/tc6.0.x/trunk/webapps/docs/changelog.xml

Modified: tomcat/tc6.0.x/trunk/STATUS
URL: 
http://svn.apache.org/viewvc/tomcat/tc6.0.x/trunk/STATUS?rev=587115&r1=587114&r2=587115&view=diff
==
--- tomcat/tc6.0.x/trunk/STATUS (original)
+++ tomcat/tc6.0.x/trunk/STATUS Mon Oct 22 07:46:04 2007
@@ -25,11 +25,6 @@
 PATCHES PROPOSED TO BACKPORT:
   [ New proposals should be added at the end of the list ]
 
-* Fix MD5 files for distribution
-  http://issues.apache.org/bugzilla/attachment.cgi?id=21009&action=view
-  +1: fhanik,funkman, markt
-  -1: 
-
 * Final fix for http://issues.apache.org/bugzilla/show_bug.cgi?id=43653
   Fixes the 100 Continue response, that got reversed through byte buffer 
manipulation
   last patch before tag, promise :)

Modified: tomcat/tc6.0.x/trunk/dist.xml
URL: 
http://svn.apache.org/viewvc/tomcat/tc6.0.x/trunk/dist.xml?rev=587115&r1=587114&r2=587115&view=diff
==
--- tomcat/tc6.0.x/trunk/dist.xml (original)
+++ tomcat/tc6.0.x/trunk/dist.xml Mon Oct 22 07:46:04 2007
@@ -51,6 +51,9 @@
   
   
 
+  
+  
+
   
   
 

Modified: tomcat/tc6.0.x/trunk/webapps/docs/changelog.xml
URL: 
http://svn.apache.org/viewvc/tomcat/tc6.0.x/trunk/webapps/docs/changelog.xml?rev=587115&r1=587114&r2=587115&view=diff
==
--- tomcat/tc6.0.x/trunk/webapps/docs/changelog.xml (original)
+++ tomcat/tc6.0.x/trunk/webapps/docs/changelog.xml Mon Oct 22 07:46:04 2007
@@ -35,6 +35,7 @@
 
   
 
+  Fix the MD5 file contents in distribution
   
 Add ANT script to be able to publish signed Tomcat JAR's to ASF Maven 
repo (fhanik)
   



-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]

Executing user code in Poller Thread for NIO connector on timeout (executor is specified in server.xml)

[Christophe Pierret]

Hi all,
I noticed that user code gets executed inside NIO Poller thread in case
of timeout error, if the executor is specified in server.xml.
Since there is very few poller threads, I guess it is not really a good
idea that the user code run in case of timeouts is run within the Poller
thread.
 
Here the call stack where it occurs for me (baseline 6.0.14).
[EMAIL PROTECTED] daemon, priority=5, in group 'main', status:
'RUNNING'
   error():149, Halley.java
   event():68, Halley.java  =>Implementation of CometProcessor.event()
   internalDoFilterEvent():470, ApplicationFilterChain.java
   doFilterEvent():363, ApplicationFilterChain.java
   event():422, StandardWrapperValve.java
   event():252, StandardContextValve.java
   event():179, StandardHostValve.java
   event():200, ValveBase.java
   event():128, StandardEngineValve.java
   event():175, CoyoteAdapter.java
   event():749, Http11NioProcessor.java
   event():637, Http11NioProtocol.java
   run():2009, NioEndpoint.java
   processSocket():1127, NioEndpoint.java
   cancelledKey():1377, NioEndpoint.java
   timeout():1611, NioEndpoint.java
   run():1452, NioEndpoint.java
   run():595, Thread.java
 
Do you think that this code could be executed within an "executor"
thread instead ?
 
I think that the following lines (in cancelledKey(),
NioEndpoint.java)may be changed from:
processSocket(ka.getChannel(), status, false);//don't dispatch if the
lines below are cancelling the key
if (status == SocketStatus.TIMEOUT ) return; // don't close on comet
timeout
 
to:
processSocket(ka.getChannel(), status, status ==
SocketStatus.TIMEOUT);//don't dispatch if the lines below are cancelling
the key
if (status == SocketStatus.TIMEOUT ) return; // don't close on comet
timeout
 
 
Best regards,
Christophe Pierret

Re: [Fwd: [Security] - **Updated** Important vulnerability disclosed in Apache Tomcat webdav servlet]

[Costin Manolache]

What is apache doing ? Better be consistent, both sides (log or no log) have
value.

( log - good to know it's happening, no-log - don't want to fill the logs
with garbage if they do it from  lots of machines / drones )

Costin
What is

On 10/21/07, Rémy Maucherat <[EMAIL PROTECTED]> wrote:
>
> On Sat, 2007-10-20 at 23:04 -0400, Mark Thomas wrote:
> > The mitigations available are:
> > - - Disable write access until a fixed version is released
> > - - Limit write access to trusted users
> > - - Apply the following patch which will be included in the next
> > releases of 6.0.x, 5.5.x and 4.1.x
>
> Since it's an obvious hacking attempt, I chose to use this method
> instead:
> documentBuilder.setEntityResolver
> (new EntityResolver() {
> public InputSource resolveEntity(String publicId,
> String systemId)
> throws SAXException, IOException {
> return new InputSource(new StringReader(""));
> }
> });
>
> -> no logging, replace with blank text (I was using an ISE right before
> instead of an input source, but there's no real justification)
>
> Rémy
>
>
>
> -
> To unsubscribe, e-mail: [EMAIL PROTECTED]
> For additional commands, e-mail: [EMAIL PROTECTED]
>
>

Re: Executing user code in Poller Thread for NIO connector on timeout (executor is specified in server.xml)

[Filip Hanik - Dev Lists]

absolutely, the other place that issues a timeout, does a dispatch, this 
one should do it too.


Filip

Christophe Pierret wrote:

Hi all,
I noticed that user code gets executed inside NIO Poller thread in case
of timeout error, if the executor is specified in server.xml.
Since there is very few poller threads, I guess it is not really a good
idea that the user code run in case of timeouts is run within the Poller
thread.
 
Here the call stack where it occurs for me (baseline 6.0.14).

[EMAIL PROTECTED] daemon, priority=5, in group 'main', status:
'RUNNING'
   error():149, Halley.java
   event():68, Halley.java  =>Implementation of CometProcessor.event()
   internalDoFilterEvent():470, ApplicationFilterChain.java
   doFilterEvent():363, ApplicationFilterChain.java
   event():422, StandardWrapperValve.java
   event():252, StandardContextValve.java
   event():179, StandardHostValve.java
   event():200, ValveBase.java
   event():128, StandardEngineValve.java
   event():175, CoyoteAdapter.java
   event():749, Http11NioProcessor.java
   event():637, Http11NioProtocol.java
   run():2009, NioEndpoint.java
   processSocket():1127, NioEndpoint.java
   cancelledKey():1377, NioEndpoint.java
   timeout():1611, NioEndpoint.java
   run():1452, NioEndpoint.java
   run():595, Thread.java
 
Do you think that this code could be executed within an "executor"

thread instead ?
 
I think that the following lines (in cancelledKey(),

NioEndpoint.java)may be changed from:
processSocket(ka.getChannel(), status, false);//don't dispatch if the
lines below are cancelling the key
if (status == SocketStatus.TIMEOUT ) return; // don't close on comet
timeout
 
to:

processSocket(ka.getChannel(), status, status ==
SocketStatus.TIMEOUT);//don't dispatch if the lines below are cancelling
the key
if (status == SocketStatus.TIMEOUT ) return; // don't close on comet
timeout
 
 
Best regards,

Christophe Pierret

  



No virus found in this incoming message.
Checked by AVG Free Edition. 
Version: 7.5.488 / Virus Database: 269.15.5/1084 - Release Date: 10/21/2007 3:09 PM
  



-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]

Re: Executing user code in Poller Thread for NIO connector on timeout (executor is specified in server.xml)

[Filip Hanik - Dev Lists]

looking at the code, I'm gonna hold off with the fix until after we tag, 
there is much cleanup to be done on this particular section


Filip

Filip Hanik - Dev Lists wrote:
absolutely, the other place that issues a timeout, does a dispatch, 
this one should do it too.


Filip

Christophe Pierret wrote:

Hi all,
I noticed that user code gets executed inside NIO Poller thread in case
of timeout error, if the executor is specified in server.xml.
Since there is very few poller threads, I guess it is not really a good
idea that the user code run in case of timeouts is run within the Poller
thread.
 
Here the call stack where it occurs for me (baseline 6.0.14).

[EMAIL PROTECTED] daemon, priority=5, in group 'main', status:
'RUNNING'
   error():149, Halley.java
   event():68, Halley.java  =>Implementation of CometProcessor.event()
   internalDoFilterEvent():470, ApplicationFilterChain.java
   doFilterEvent():363, ApplicationFilterChain.java
   event():422, StandardWrapperValve.java
   event():252, StandardContextValve.java
   event():179, StandardHostValve.java
   event():200, ValveBase.java
   event():128, StandardEngineValve.java
   event():175, CoyoteAdapter.java
   event():749, Http11NioProcessor.java
   event():637, Http11NioProtocol.java
   run():2009, NioEndpoint.java
   processSocket():1127, NioEndpoint.java
   cancelledKey():1377, NioEndpoint.java
   timeout():1611, NioEndpoint.java
   run():1452, NioEndpoint.java
   run():595, Thread.java
 
Do you think that this code could be executed within an "executor"

thread instead ?
 
I think that the following lines (in cancelledKey(),

NioEndpoint.java)may be changed from:
processSocket(ka.getChannel(), status, false);//don't dispatch if the
lines below are cancelling the key
if (status == SocketStatus.TIMEOUT ) return; // don't close on comet
timeout
 
to:

processSocket(ka.getChannel(), status, status ==
SocketStatus.TIMEOUT);//don't dispatch if the lines below are cancelling
the key
if (status == SocketStatus.TIMEOUT ) return; // don't close on comet
timeout
 
 
Best regards,

Christophe Pierret

  



No virus found in this incoming message.
Checked by AVG Free Edition. Version: 7.5.488 / Virus Database: 
269.15.5/1084 - Release Date: 10/21/2007 3:09 PM
  



-
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]

DO NOT REPLY [Bug 43671] - Unclear Contract between Entity expansion and DOM parser validation cause OWASP A2 in WebDAV Servlet

[bugzilla]

DO NOT REPLY TO THIS EMAIL, BUT PLEASE POST YOUR BUG·
RELATED COMMENTS THROUGH THE WEB INTERFACE AVAILABLE AT
.
ANY REPLY MADE TO THIS MESSAGE WILL NOT BE COLLECTED AND·
INSERTED IN THE BUG DATABASE.

http://issues.apache.org/bugzilla/show_bug.cgi?id=43671





--- Additional Comments From [EMAIL PROTECTED]  2007-10-22 11:25 ---
I've tested pre-patch and post-patch and Mark's new patch seems to do what it is
supposed to do. 

Re: logging.
I personally prefer to put the onus on the user to manage their logs.

-- 
Configure bugmail: http://issues.apache.org/bugzilla/userprefs.cgi?tab=email
--- You are receiving this mail because: ---
You are the assignee for the bug, or are watching the assignee.

-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]

Re: [Fwd: [Security] - **Updated** Important vulnerability disclosed in Apache Tomcat webdav servlet]

[William L. Thomson Jr.]

On Sun, 2007-10-21 at 14:03 -0400, William L. Thomson Jr. wrote:
> On Sun, 2007-10-21 at 17:41 +0100, Mark Thomas wrote:
> > William L. Thomson Jr. wrote:
> > > I take it down streams should run with the first patches to work around
> > > this vulnerability till next release. I already applied the one liner,
> > > kinda glad I did not apply the other last night ;) Please advise,
> > > thanks.
> > 
> > You need a version of the second patch for a complete fix. If you want
> > logging - apply my version, if you don't - apply Remy's. Both fix the
> > problem, just in slightly different ways.
> > 
> > We'll have to wait and see which way the voting goes for which patch
> > gets incorporated into the code base.
> 
> That's what I am interested in, and willing to wait a bit for. Don't
> want to appear to be taking sides or adding in my own opinion based on
> which one to apply/go with or not. Prefer to stick with what ever
> direction upstream goes in and/or recommends.
> 

For what it's worth, I am thinking logging might be best. Mostly because
to my understanding one must be authorized in webdav or etc to be able
to exploit the vulnerability. So it's more of an attack from within, and
IMHO it's even more important to log those. It's one thing to be
attacked from the outside world, but being attacked from within can be
worse. Since in theory they are trusted to a point.

Either way I do agree with the other post on being consistent with other
projects.

-- 
William L. Thomson Jr.
Gentoo/Java


signature.asc
Description: This is a digitally signed message part

Measuring bytes sent and received from and to Tomcat

[Dave Rathnow]

We have an application that collects data from, and sends data to,
remote embedded devices.  Traditionally we have used TCP and UDP to send
and receive data over satellite.  The latest release of our product will
be using other communication medium with our devices making HTTP request
to our application that is running under JBoss/Tomcat.   
 
The way we bill our clients is by charging them a usage fee based on the
number of bytes being sent over the air/wire.  Because of this, we need
to have a accurate count of the number of bytes sent and received from
each site, which is uniquely identified by it's IP address.  Using
either UDP and TCP this is simple as we are in control of the end
socket.
 
Is there a way we can do the same thing with Tomcat?  It's simple for us
to measure the number of byte in the payload of the HTTP
request/response, however that isn't enough.  We need to know the total
number of bytes being sent and received for each HTTP request.

Can someone suggest a way I could get an accurate count of these bytes?
 
Thanks,
Dave.

-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]

Re: Measuring bytes sent and received from and to Tomcat

[Yoav Shapira]

Hey,

On 10/22/07, Dave Rathnow <[EMAIL PROTECTED]> wrote:
> Is there a way we can do the same thing with Tomcat?  It's simple for us
> to measure the number of byte in the payload of the HTTP
> request/response, however that isn't enough.  We need to know the total
> number of bytes being sent and received for each HTTP request.
>
> Can someone suggest a way I could get an accurate count of these bytes?

You can probably start with the AccessLogValve that ships with Tomcat:
http://tomcat.apache.org/tomcat-6.0-doc/config/valve.html

Out of the box it will get you the complete bytes in the response.
See the above docs on how to configure that.  If you want to log the
complete bytes on the request, I think you'll have to extend the
Valve, but it should be pretty easy to do.

Yoav

-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]

[LOBBYING] Final fix for NIO connector

[Filip Hanik - Dev Lists]

Wanted to make sure you got a chance to vote for this, the fix must 
include the 100-continue response as well


Please vote
Filip

* Final fix for http://issues.apache.org/bugzilla/show_bug.cgi?id=43653
 Fixes the 100 Continue response, that got reversed through byte buffer 
manipulation

 last patch before tag, promise :)
 http://people.apache.org/~fhanik/patches/bz-43653-complimentary.patch


-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]

RE: Measuring bytes sent and received from and to Tomcat

[Dave Rathnow]

We looked at using a valve but we weren't sure if it would work.
Correct me if I'm wrong, but it appears as though valves are chained
together in a calling sequence and that some valves could change the
content of the request or response.  This means we may not get an
accurate measure of the number of total number bytes that make up the
request.

Also, the AccessLogValve has a pattern code to get the number of bytes
sent, excluding the HTTP headers, but does not have a pattern code to
get the number of bytes sent, including the HTTP headers, which is what
we really need.

Have I missed something?

Dave.
   

-Original Message-
From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED] On Behalf Of
Yoav Shapira
Sent: October 22, 2007 02:36 PM
To: Tomcat Developers List
Subject: Re: Measuring bytes sent and received from and to Tomcat

Hey,

On 10/22/07, Dave Rathnow <[EMAIL PROTECTED]> wrote:
> Is there a way we can do the same thing with Tomcat?  It's simple for 
> us to measure the number of byte in the payload of the HTTP 
> request/response, however that isn't enough.  We need to know the 
> total number of bytes being sent and received for each HTTP request.
>
> Can someone suggest a way I could get an accurate count of these
bytes?

You can probably start with the AccessLogValve that ships with Tomcat:
http://tomcat.apache.org/tomcat-6.0-doc/config/valve.html

Out of the box it will get you the complete bytes in the response.
See the above docs on how to configure that.  If you want to log the
complete bytes on the request, I think you'll have to extend the Valve,
but it should be pretty easy to do.

Yoav

-
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]

Re: Measuring bytes sent and received from and to Tomcat

[Costin Manolache]

'bytes' should be counted at a lower level, in connector. I'm not sure this
is something generic enough - but you can make some changes to your tomcat,
where read() is done from socket.

I guess it would be nice to have a JMX graph with bytes/sec in/out.

Costin
'bytes'

On 10/22/07, Dave Rathnow <[EMAIL PROTECTED]> wrote:
>
>
> We looked at using a valve but we weren't sure if it would work.
> Correct me if I'm wrong, but it appears as though valves are chained
> together in a calling sequence and that some valves could change the
> content of the request or response.  This means we may not get an
> accurate measure of the number of total number bytes that make up the
> request.
>
> Also, the AccessLogValve has a pattern code to get the number of bytes
> sent, excluding the HTTP headers, but does not have a pattern code to
> get the number of bytes sent, including the HTTP headers, which is what
> we really need.
>
> Have I missed something?
>
> Dave.
>
>
> -Original Message-
> From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED] On Behalf Of
> Yoav Shapira
> Sent: October 22, 2007 02:36 PM
> To: Tomcat Developers List
> Subject: Re: Measuring bytes sent and received from and to Tomcat
>
> Hey,
>
> On 10/22/07, Dave Rathnow <[EMAIL PROTECTED]> wrote:
> > Is there a way we can do the same thing with Tomcat?  It's simple for
> > us to measure the number of byte in the payload of the HTTP
> > request/response, however that isn't enough.  We need to know the
> > total number of bytes being sent and received for each HTTP request.
> >
> > Can someone suggest a way I could get an accurate count of these
> bytes?
>
> You can probably start with the AccessLogValve that ships with Tomcat:
> http://tomcat.apache.org/tomcat-6.0-doc/config/valve.html
>
> Out of the box it will get you the complete bytes in the response.
> See the above docs on how to configure that.  If you want to log the
> complete bytes on the request, I think you'll have to extend the Valve,
> but it should be pretty easy to do.
>
> Yoav
>
> -
> 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]
>
>

RE: Measuring bytes sent and received from and to Tomcat

[Dave Rathnow]

I looked at connectors but wasn't sure if this was what I wanted.  To
avoid anther wild goose chase I decided to ask.  Can you point me in the
direction of some documentation where I might be able to get started?

Dave. 

-Original Message-
From: Costin Manolache [mailto:[EMAIL PROTECTED] 
Sent: October 22, 2007 04:28 PM
To: Tomcat Developers List
Subject: Re: Measuring bytes sent and received from and to Tomcat

'bytes' should be counted at a lower level, in connector. I'm not sure
this is something generic enough - but you can make some changes to your
tomcat, where read() is done from socket.

I guess it would be nice to have a JMX graph with bytes/sec in/out.

Costin
'bytes'

On 10/22/07, Dave Rathnow <[EMAIL PROTECTED]> wrote:
>
>
> We looked at using a valve but we weren't sure if it would work.
> Correct me if I'm wrong, but it appears as though valves are chained 
> together in a calling sequence and that some valves could change the 
> content of the request or response.  This means we may not get an 
> accurate measure of the number of total number bytes that make up the 
> request.
>
> Also, the AccessLogValve has a pattern code to get the number of bytes

> sent, excluding the HTTP headers, but does not have a pattern code to 
> get the number of bytes sent, including the HTTP headers, which is 
> what we really need.
>
> Have I missed something?
>
> Dave.
>
>
> -Original Message-
> From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED] On Behalf 
> Of Yoav Shapira
> Sent: October 22, 2007 02:36 PM
> To: Tomcat Developers List
> Subject: Re: Measuring bytes sent and received from and to Tomcat
>
> Hey,
>
> On 10/22/07, Dave Rathnow <[EMAIL PROTECTED]> wrote:
> > Is there a way we can do the same thing with Tomcat?  It's simple 
> > for us to measure the number of byte in the payload of the HTTP 
> > request/response, however that isn't enough.  We need to know the 
> > total number of bytes being sent and received for each HTTP request.
> >
> > Can someone suggest a way I could get an accurate count of these
> bytes?
>
> You can probably start with the AccessLogValve that ships with Tomcat:
> http://tomcat.apache.org/tomcat-6.0-doc/config/valve.html
>
> Out of the box it will get you the complete bytes in the response.
> See the above docs on how to configure that.  If you want to log the 
> complete bytes on the request, I think you'll have to extend the 
> Valve, but it should be pretty easy to do.
>
> Yoav
>
> -
> 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]
>
>

-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]

Re: Measuring bytes sent and received from and to Tomcat

[Costin Manolache]

Well, if you want absolute byte - connector seems the only place, there are
space and tabs beeing skipped when parsing headers, etc.

If you are ok with an estimate - the AccessLogValve is ok, add all the
header lengths + method + http/1.1. You'll miss bytes for encodings, spaces.

Re. where to add - each connector is different on how it reads/parse the
message, you probably want to do it close to the 'read()' call, save it
somewhere associated with the request ( a note or attribute ) and read it in
a valve or filter.

Costin


On 10/22/07, Dave Rathnow <[EMAIL PROTECTED]> wrote:
>
>
> I looked at connectors but wasn't sure if this was what I wanted.  To
> avoid anther wild goose chase I decided to ask.  Can you point me in the
> direction of some documentation where I might be able to get started?
>
> Dave.
>
> -Original Message-
> From: Costin Manolache [mailto:[EMAIL PROTECTED]
> Sent: October 22, 2007 04:28 PM
> To: Tomcat Developers List
> Subject: Re: Measuring bytes sent and received from and to Tomcat
>
> 'bytes' should be counted at a lower level, in connector. I'm not sure
> this is something generic enough - but you can make some changes to your
> tomcat, where read() is done from socket.
>
> I guess it would be nice to have a JMX graph with bytes/sec in/out.
>
> Costin
> 'bytes'
>
> On 10/22/07, Dave Rathnow <[EMAIL PROTECTED]> wrote:
> >
> >
> > We looked at using a valve but we weren't sure if it would work.
> > Correct me if I'm wrong, but it appears as though valves are chained
> > together in a calling sequence and that some valves could change the
> > content of the request or response.  This means we may not get an
> > accurate measure of the number of total number bytes that make up the
> > request.
> >
> > Also, the AccessLogValve has a pattern code to get the number of bytes
>
> > sent, excluding the HTTP headers, but does not have a pattern code to
> > get the number of bytes sent, including the HTTP headers, which is
> > what we really need.
> >
> > Have I missed something?
> >
> > Dave.
> >
> >
> > -Original Message-
> > From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED] On Behalf
> > Of Yoav Shapira
> > Sent: October 22, 2007 02:36 PM
> > To: Tomcat Developers List
> > Subject: Re: Measuring bytes sent and received from and to Tomcat
> >
> > Hey,
> >
> > On 10/22/07, Dave Rathnow <[EMAIL PROTECTED]> wrote:
> > > Is there a way we can do the same thing with Tomcat?  It's simple
> > > for us to measure the number of byte in the payload of the HTTP
> > > request/response, however that isn't enough.  We need to know the
> > > total number of bytes being sent and received for each HTTP request.
> > >
> > > Can someone suggest a way I could get an accurate count of these
> > bytes?
> >
> > You can probably start with the AccessLogValve that ships with Tomcat:
> > http://tomcat.apache.org/tomcat-6.0-doc/config/valve.html
> >
> > Out of the box it will get you the complete bytes in the response.
> > See the above docs on how to configure that.  If you want to log the
> > complete bytes on the request, I think you'll have to extend the
> > Valve, but it should be pretty easy to do.
> >
> > Yoav
> >
> > -
> > 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]
> >
> >
>

Re: [Fwd: [Security] - **Updated** Important vulnerability disclosed in Apache Tomcat webdav servlet]

[Mark Thomas]

William L. Thomson Jr. wrote:

> Mostly because
> to my understanding one must be authorized in webdav or etc to be able
> to exploit the vulnerability.

To be clear, authorisation is not required for this vulnerability. Of
course, if you open up write access without authorisation then you are
taking on a whole bunch of other risks.

Mark


-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]

svn commit: r587315 [4/4] - in /tomcat/site/trunk: docs/ docs/faq/ docs/faq/printer/ xdocs/ xdocs/stylesheets/

[markt]

Modified: tomcat/site/trunk/docs/security.html
URL: 
http://svn.apache.org/viewvc/tomcat/site/trunk/docs/security.html?rev=587315&r1=587314&r2=587315&view=diff
==
--- tomcat/site/trunk/docs/security.html (original)
+++ tomcat/site/trunk/docs/security.html Mon Oct 22 17:16:38 2007
@@ -66,7 +66,7 @@
 Tomcat 6.x
 
 
-Tomcat 5.x
+Tomcat 5.5
 
 
 Tomcat 4.1
@@ -90,9 +90,6 @@
 
 
 Tomcat 5.5
-
-
-Tomcat 5.0
 
 
 Tomcat 4.1

Modified: tomcat/site/trunk/docs/svn.html
URL: 
http://svn.apache.org/viewvc/tomcat/site/trunk/docs/svn.html?rev=587315&r1=587314&r2=587315&view=diff
==
--- tomcat/site/trunk/docs/svn.html (original)
+++ tomcat/site/trunk/docs/svn.html Mon Oct 22 17:16:38 2007
@@ -64,7 +64,7 @@
 Tomcat 6.x
 
 
-Tomcat 5.x
+Tomcat 5.5
 
 
 Tomcat 4.1
@@ -88,9 +88,6 @@
 
 
 Tomcat 5.5
-
-
-Tomcat 5.0
 
 
 Tomcat 4.1

Modified: tomcat/site/trunk/docs/whichversion.html
URL: 
http://svn.apache.org/viewvc/tomcat/site/trunk/docs/whichversion.html?rev=587315&r1=587314&r2=587315&view=diff
==
--- tomcat/site/trunk/docs/whichversion.html (original)
+++ tomcat/site/trunk/docs/whichversion.html Mon Oct 22 17:16:38 2007
@@ -68,7 +68,7 @@
 Tomcat 6.x
 
 
-Tomcat 5.x
+Tomcat 5.5
 
 
 Tomcat 4.1
@@ -94,9 +94,6 @@
 Tomcat 5.5
 
 
-Tomcat 5.0
-
-
 Tomcat 4.1
 
 
@@ -300,7 +297,7 @@
 expected to run stably for any length of time.
 
 
-Beta releases may contain some untested functionlaity and/or a
+Beta releases may contain some untested functionality and/or a
 number of relatively minor bugs. Beta releases are not expected to run 
stably.
 
 
@@ -429,11 +426,6 @@
 specifications.
 
 
-We encourage all users to upgrade to Apache Tomcat 5.x whenever
-possible.
-
-
-
 Apache Tomcat 4.1.x. Apache Tomcat 4.1 is a refactoring
 of Apache Tomcat 4.0.x, and contains significant enhancements, including:
 
@@ -458,11 +450,6 @@
 also supports web applications built for the Servlet 2.2 and JSP 1.1
 specifications with no changes.
 
-
-We encourage all users to upgrade to Apache Tomcat 5.x whenever
-possible.
-
-
 
 
 
@@ -539,11 +526,6 @@
 
 
 Apache Tomcat 3.0.x. Initial Apache Tomcat release.
-
-
-We encourage all users to upgrade to Apache Tomcat 5.x whenever
-possible.
-
 
 
 

Modified: tomcat/site/trunk/docs/whoweare.html
URL: 
http://svn.apache.org/viewvc/tomcat/site/trunk/docs/whoweare.html?rev=587315&r1=587314&r2=587315&view=diff
==
--- tomcat/site/trunk/docs/whoweare.html (original)
+++ tomcat/site/trunk/docs/whoweare.html Mon Oct 22 17:16:38 2007
@@ -64,7 +64,7 @@
 Tomcat 6.x
 
 
-Tomcat 5.x
+Tomcat 5.5
 
 
 Tomcat 4.1
@@ -88,9 +88,6 @@
 
 
 Tomcat 5.5
-
-
-Tomcat 5.0
 
 
 Tomcat 4.1

Modified: tomcat/site/trunk/xdocs/download-55.xml
URL: 
http://svn.apache.org/viewvc/tomcat/site/trunk/xdocs/download-55.xml?rev=587315&r1=587314&r2=587315&view=diff
==
--- tomcat/site/trunk/xdocs/download-55.xml (original)
+++ tomcat/site/trunk/xdocs/download-55.xml Mon Oct 22 17:16:38 2007
@@ -7,8 +7,8 @@
 
   
 Welcome to the Tomcat 5.x download page.  This page provides download
-links for obtaining the latest versions of all Tomcat release branches, as
-well as links to the archives of older releases.
+links for obtaining the latest versions of Tomcat 5.5.x, as
+well as links to the archives of older 5.0.x and 5.5.x releases.
 
   
 
@@ -16,8 +16,6 @@
   
 http://www.apache.org/dist/tomcat/tomcat-5/KEYS";>KEYS |
 5.5.25 |
-5.0.30-beta |
-5.0.28 |
 http://archive.apache.org/dist/tomcat/tomcat-5";>Archives
   
   
@@ -177,173 +175,6 @@
  
  
  
-
-  
-  
-  
-  Please see the 
-  README
-  file for packaging information.  It explains what every distribution 
contains.
-  
-
-  
-  
-Core:
-  
-  
-zip
 
-http://www.apache.org/dist/tomcat/tomcat-5/v5.0.30/bin/jakarta-tomcat-5.0.30.zip.asc";>pgp,
 
-http://www.apache.org/dist/tomcat/tomcat-5/v5.0.30/bin/jakarta-tomcat-5.0.30.zip.md5";>md5)
-  
-  
-tar.gz
 
-(http://www.apache.org/dist/tomcat/tomcat-5/v5.0.30/bin/jakarta-tomcat-5.0.30.tar.gz.asc";>pgp,
 
-http://www.apache.org/dist/tomcat/tomcat-5/v5.0.30/bin/jakarta-tomcat-5.0.30.tar.gz.md5";>md5)
-  
-  
-Windows
 Service Installer 
-(http://www.apache.org/dist/tomcat/tomcat-5/v5.0.30/bin/jakarta-tomcat-5.0.30.exe.asc";>pgp,
 
-http://www.apache.org/dist/tomcat/tomcat-5/v5.0.30/bin/jakarta-tomcat-5.0.30.exe.md5";>md5)
-  
-  
-
-Deployer:
-  
- 

[ANN] Apache Tomcat 5.0.x no longer supported

[Mark Thomas]

The Apache Tomcat team wishes to announce that Tomcat 5.0.x will no
longer be supported.

Users are encouraged to upgrade to the latest stable 6.x release or,
if that is not practical, the latest stable 5.5.x for continued support.

Kind regards,

The Apache Tomcat team

-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]

DO NOT REPLY [Bug 38290] - No SESSION_DESTROYED_EVENT sent for existing webapp sessions when webapp is reloaded

[bugzilla]

DO NOT REPLY TO THIS EMAIL, BUT PLEASE POST YOUR BUG·
RELATED COMMENTS THROUGH THE WEB INTERFACE AVAILABLE AT
.
ANY REPLY MADE TO THIS MESSAGE WILL NOT BE COLLECTED AND·
INSERTED IN THE BUG DATABASE.

http://issues.apache.org/bugzilla/show_bug.cgi?id=38290


[EMAIL PROTECTED] changed:

   What|Removed |Added

 Status|NEEDINFO|RESOLVED
 Resolution||INVALID




--- Additional Comments From [EMAIL PROTECTED]  2007-10-22 17:41 ---
Closing assuming lack of response from OP means Yoav's advice fixed the problem.

-- 
Configure bugmail: http://issues.apache.org/bugzilla/userprefs.cgi?tab=email
--- You are receiving this mail because: ---
You are the assignee for the bug, or are watching the assignee.

-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]

DO NOT REPLY [Bug 38291] - Form actions hanging in UDecoder.convert

[bugzilla]

DO NOT REPLY TO THIS EMAIL, BUT PLEASE POST YOUR BUG·
RELATED COMMENTS THROUGH THE WEB INTERFACE AVAILABLE AT
.
ANY REPLY MADE TO THIS MESSAGE WILL NOT BE COLLECTED AND·
INSERTED IN THE BUG DATABASE.

http://issues.apache.org/bugzilla/show_bug.cgi?id=38291


[EMAIL PROTECTED] changed:

   What|Removed |Added

 Status|NEEDINFO|RESOLVED
 Resolution||WONTFIX




--- Additional Comments From [EMAIL PROTECTED]  2007-10-22 17:43 ---
Without information to reproduce there is little we can do with this.

-- 
Configure bugmail: http://issues.apache.org/bugzilla/userprefs.cgi?tab=email
--- You are receiving this mail because: ---
You are the assignee for the bug, or are watching the assignee.

-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]

DO NOT REPLY [Bug 38629] - Classloader not quickly enough available for JSPs

[bugzilla]

DO NOT REPLY TO THIS EMAIL, BUT PLEASE POST YOUR BUG·
RELATED COMMENTS THROUGH THE WEB INTERFACE AVAILABLE AT
.
ANY REPLY MADE TO THIS MESSAGE WILL NOT BE COLLECTED AND·
INSERTED IN THE BUG DATABASE.

http://issues.apache.org/bugzilla/show_bug.cgi?id=38629


[EMAIL PROTECTED] changed:

   What|Removed |Added

 Status|NEEDINFO|RESOLVED
 Resolution||WONTFIX




--- Additional Comments From [EMAIL PROTECTED]  2007-10-22 17:45 ---
Without steps to reproduce we can't do anything.

-- 
Configure bugmail: http://issues.apache.org/bugzilla/userprefs.cgi?tab=email
--- You are receiving this mail because: ---
You are the assignee for the bug, or are watching the assignee.

-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]

DO NOT REPLY [Bug 38795] - [PATCH] StandardContext doesn't always reset thread's contextClassLoader

[bugzilla]

DO NOT REPLY TO THIS EMAIL, BUT PLEASE POST YOUR BUG·
RELATED COMMENTS THROUGH THE WEB INTERFACE AVAILABLE AT
.
ANY REPLY MADE TO THIS MESSAGE WILL NOT BE COLLECTED AND·
INSERTED IN THE BUG DATABASE.

http://issues.apache.org/bugzilla/show_bug.cgi?id=38795


[EMAIL PROTECTED] changed:

   What|Removed |Added

 Status|REOPENED|RESOLVED
 Resolution||WONTFIX




--- Additional Comments From [EMAIL PROTECTED]  2007-10-22 17:47 ---
This will nto be fixed in 5.0.x since that branch is no longer supported.

-- 
Configure bugmail: http://issues.apache.org/bugzilla/userprefs.cgi?tab=email
--- You are receiving this mail because: ---
You are the assignee for the bug, or are watching the assignee.

-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]

DO NOT REPLY [Bug 39358] - tomcat can not support the JAASRealm definition with character "$" in the class name.

[bugzilla]

DO NOT REPLY TO THIS EMAIL, BUT PLEASE POST YOUR BUG·
RELATED COMMENTS THROUGH THE WEB INTERFACE AVAILABLE AT
.
ANY REPLY MADE TO THIS MESSAGE WILL NOT BE COLLECTED AND·
INSERTED IN THE BUG DATABASE.

http://issues.apache.org/bugzilla/show_bug.cgi?id=39358


[EMAIL PROTECTED] changed:

   What|Removed |Added

 Status|NEEDINFO|RESOLVED
 Resolution||WONTFIX




--- Additional Comments From [EMAIL PROTECTED]  2007-10-22 17:52 ---
This is fixed in 5.5.x
5.0.x is no longer supported.

-- 
Configure bugmail: http://issues.apache.org/bugzilla/userprefs.cgi?tab=email
--- You are receiving this mail because: ---
You are the assignee for the bug, or are watching the assignee.

-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]

mod_jk 1.2.25, JkEnvVar evaluated too many times

[Ian Ward Comfort]

(I've heard this list is a good place to discuss mod_jk code; please  
redirect me and accept my apologies if it is not.)


I think I've found a problem with mod_jk 1.2.25 and Apache 2.x,  
whereby JkEnvVar directives are effectively evaluated too many times  
when VirtualHosts are configured.


The problem is apparent on a RHEL4 server of mine running Apache  
2.2.6, with 17 name-based virtual hosts configured for *:80.  I have  
13 JkEnvVars specified, all with default values, in the main server  
configuration.  There are no JK directives within the virtual host  
containers.  By adding some additional instrumentation to the code, I  
can see that each AJP packet is constructed with ((1 + 17) * 13) =  
234 envvar attributes -- the whole set of attributes is appended 18  
times in succession.  (Often this overflows the default maximum  
packet size.)


The source of the trouble seems to be in native/apache-2.0/mod_jk.c,  
in the jk_post_config function, specifically lines 2853-2879 of the  
1.2.25 source.  This code is evaluated many times for the same sconf  
object, as each iteration through the enclosing for loop has a  
different server object, but ap_get_module_config returns the same  
jk_server_conf_t* for all of them.


I would submit a patch for this but I'm no expert in coding Apache  
modules, and I don't want to speculate about the way these  
configurations should be constructed.  If I should dig deeper and  
develop a fix, or provide more information, let me know.


Thanks,
--
Ian Ward Comfort <[EMAIL PROTECTED]>
System Administrator, Student Computing, Stanford University


-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]

DO NOT REPLY [Bug 43671] - Unclear Contract between Entity expansion and DOM parser validation cause OWASP A2 in WebDAV Servlet

[bugzilla]

DO NOT REPLY TO THIS EMAIL, BUT PLEASE POST YOUR BUG·
RELATED COMMENTS THROUGH THE WEB INTERFACE AVAILABLE AT
.
ANY REPLY MADE TO THIS MESSAGE WILL NOT BE COLLECTED AND·
INSERTED IN THE BUG DATABASE.

http://issues.apache.org/bugzilla/show_bug.cgi?id=43671


[EMAIL PROTECTED] changed:

   What|Removed |Added

 Status|NEW |RESOLVED
 Resolution||FIXED




--- Additional Comments From [EMAIL PROTECTED]  2007-10-22 17:55 ---
A work around exists in TC6. The root cause appears to be a JDK issue.

-- 
Configure bugmail: http://issues.apache.org/bugzilla/userprefs.cgi?tab=email
--- You are receiving this mail because: ---
You are the assignee for the bug, or are watching the assignee.

-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]

Re: [Fwd: [Security] - **Updated** Important vulnerability disclosed in Apache Tomcat webdav servlet]

[William L. Thomson Jr.]

On Tue, 2007-10-23 at 00:39 +0100, Mark Thomas wrote:
> William L. Thomson Jr. wrote:
> 
> > Mostly because
> > to my understanding one must be authorized in webdav or etc to be able
> > to exploit the vulnerability.
> 
> To be clear, authorisation is not required for this vulnerability. Of
> course, if you open up write access without authorisation then you are
> taking on a whole bunch of other risks.

Thanks for the clarification.

This was misleading
http://nvd.nist.gov/nvd.cfm?cvename=CVE-2007-5461

This one is not as clear, but implies via remote authenticated users
http://cve.mitre.org/cgi-bin/cvename.cgi?name=CVE-2007-5461

Could be all are assuming no one in their right educated mind would open
write access up to the world. But ya never know :)

-- 
William L. Thomson Jr.
Gentoo/Java


signature.asc
Description: This is a digitally signed message part

Re: Measuring bytes sent and received from and to Tomcat

[Johnny Kewl]

---
HARBOR: http://coolharbor.100free.com/index.htm
Now Tomcat is also a cool application server
---
- Original Message - 
From: "Dave Rathnow" <[EMAIL PROTECTED]>

To: "Tomcat Developers List" 
Sent: Monday, October 22, 2007 10:00 PM
Subject: Measuring bytes sent and received from and to Tomcat

=
Hi there, interesting question, more I think about it, more complicated it 
gets ;)


Dont think its easy from TC, its too sophisticated, compression, SSL, 
redirects, dispatches, clustering... think its hard to get a true network 
measurement.


I would plunder something like TCPMon 
https://tcpmon.dev.java.net/source/browse/tcpmon/

Its a NB plugin so can play with it first

Its really just a (bind - client) ie port 8080 to 8081 type idea - so its 
easy to install, and easy to setup across multiple sites, clusters etc etc.


Steal this (relay or tunnel) code and just mod it... I think you will be 
able to modify it for client IP's cookies, special headers... anything
and then call it from a browser and get client billing breakdowns 
maybe...


==
We have an application that collects data from, and sends data to,
remote embedded devices.  Traditionally we have used TCP and UDP to send
and receive data over satellite.  The latest release of our product will
be using other communication medium with our devices making HTTP request
to our application that is running under JBoss/Tomcat.

The way we bill our clients is by charging them a usage fee based on the
number of bytes being sent over the air/wire.  Because of this, we need
to have a accurate count of the number of bytes sent and received from
each site, which is uniquely identified by it's IP address.  Using
either UDP and TCP this is simple as we are in control of the end
socket.

Is there a way we can do the same thing with Tomcat?  It's simple for us
to measure the number of byte in the payload of the HTTP
request/response, however that isn't enough.  We need to know the total
number of bytes being sent and received for each HTTP request.

Can someone suggest a way I could get an accurate count of these bytes?

Thanks,
Dave.

-
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]

Re: mod_jk 1.2.25, JkEnvVar evaluated too many times

[Mladen Turk]

Ian Ward Comfort wrote:
(I've heard this list is a good place to discuss mod_jk code; please 
redirect me and accept my apologies if it is not.)




No, this is correct place :)

containers.  By adding some additional instrumentation to the code, I 
can see that each AJP packet is constructed with ((1 + 17) * 13) = 234 
envvar attributes -- the whole set of attributes is appended 18 times in 
succession.  (Often this overflows the default maximum packet size.)




Can you use JkLogLevel debug and attach the packet dumps as well as the
the config?

Regards,
Mladen

-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]