DO NOT REPLY [Bug 10383] - Specially crafted GET request causes the answering httpd process and the answering AJP13 processor to hang indefinitely
DO NOT REPLY TO THIS EMAIL, BUT PLEASE POST YOUR BUG RELATED COMMENTS THROUGH THE WEB INTERFACE AVAILABLE AT http://nagoya.apache.org/bugzilla/show_bug.cgi?id=10383. ANY REPLY MADE TO THIS MESSAGE WILL NOT BE COLLECTED AND INSERTED IN THE BUG DATABASE. http://nagoya.apache.org/bugzilla/show_bug.cgi?id=10383 Specially crafted GET request causes the answering httpd process and the answering AJP13 processor to hang indefinitely [EMAIL PROTECTED] changed: What|Removed |Added AssignedTo|tomcat- |[EMAIL PROTECTED] |[EMAIL PROTECTED] | Status|CLOSED |NEW - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
DO NOT REPLY [Bug 10383] - Specially crafted GET request causes the answering httpd process and the answering AJP13 processor to hang indefinitely
DO NOT REPLY TO THIS EMAIL, BUT PLEASE POST YOUR BUG RELATED COMMENTS THROUGH THE WEB INTERFACE AVAILABLE AT http://nagoya.apache.org/bugzilla/show_bug.cgi?id=10383. ANY REPLY MADE TO THIS MESSAGE WILL NOT BE COLLECTED AND INSERTED IN THE BUG DATABASE. http://nagoya.apache.org/bugzilla/show_bug.cgi?id=10383 Specially crafted GET request causes the answering httpd process and the answering AJP13 processor to hang indefinitely --- Additional Comments From [EMAIL PROTECTED] 2003-01-04 22:28 --- Thank you very much for the patch. Especially the second version of the patch is exactly what I had in mind when I wrote this bug report. One last general request that is not focused on you: When I encounter problems with apache.org software (not only Tomcat) I use bugzilla very often and most of the time I find a hint there that solves my problem. But very often it is hard work to find all the patched files and the revisions of the files containing the patch that resolved the bug in the CVS (partionally CVS is to blame on this problem). Although I know that the CVS is very dynamic, I think it would help a lot if any person who commits a patch to the CVS in reaction to a bug report writes a short note to the bug report which files have been changed by the patch and the revision numbers of these files. Even if these patches change later on, this information is a good base for searching the actual version of the patch to a bug in the CVS. For this bug the note is rather short: Affected files and revisions: jakarta-tomcat-connectors/jk/java/org/apache/ajp/tomcat4/Ajp13Processor.java revisions: 1.10, 1.11 Complete patch: http://cvs.apache.org/viewcvs/jakarta-tomcat-connectors/jk/java/org/apache/ajp/tomcat4/Ajp13Processor.java.diff?r1=1.9r2=1.11 Remark: The complete patch line is something I would not see within the scope of this short note in general, but in this case this was so easy that I added it for everyones convenience. Again thanks for the help. -- To unsubscribe, e-mail: mailto:[EMAIL PROTECTED] For additional commands, e-mail: mailto:[EMAIL PROTECTED]
RE: DO NOT REPLY [Bug 10383] - Specially crafted GET request causes the answering httpd process and the answering AJP13 processor to hang indefinitely
CVSZilla (http://homepages.kcbbs.gen.nz/~tonyg/) supports this kind of functionality quite nicely. Sean Reilly Software Architect, Point2 Technologies, Inc. (306) 955-1855 [EMAIL PROTECTED] -Original Message- (snip) One last general request that is not focused on you: When I encounter problems with apache.org software (not only Tomcat) I use bugzilla very often and most of the time I find a hint there that solves my problem. But very often it is hard work to find all the patched files and the revisions of the files containing the patch that resolved the bug in the CVS (partionally CVS is to blame on this problem). Although I know that the CVS is very dynamic, I think it would help a lot if any person who commits a patch to the CVS in reaction to a bug report writes a short note to the bug report which files have been changed by the patch and the revision numbers of these files. Even if these patches change later on, this information is a good base for searching the actual version of the patch to a bug in the CVS. For this bug the note is rather short: Affected files and revisions: jakarta-tomcat-connectors/jk/java/org/apache/ajp/tomcat4/Ajp13 Processor.java revisions: 1.10, 1.11 Complete patch: http://cvs.apache.org/viewcvs/jakarta-tomcat-connectors/jk/jav a/org/apache/ajp/tomcat4/Ajp13Processor.java.diff?r1=1.9r2=1.11 Remark: The complete patch line is something I would not see within the scope of this short note in general, but in this case this was so easy that I added it for everyones convenience. Again thanks for the help. -- To unsubscribe, e-mail: mailto:[EMAIL PROTECTED] For additional commands, e-mail: mailto:[EMAIL PROTECTED] -- To unsubscribe, e-mail: mailto:[EMAIL PROTECTED] For additional commands, e-mail: mailto:[EMAIL PROTECTED]
DO NOT REPLY [Bug 10383] - Specially crafted GET request causes the answering httpd process and the answering AJP13 processor to hang indefinitely
DO NOT REPLY TO THIS EMAIL, BUT PLEASE POST YOUR BUG RELATED COMMENTS THROUGH THE WEB INTERFACE AVAILABLE AT http://nagoya.apache.org/bugzilla/show_bug.cgi?id=10383. ANY REPLY MADE TO THIS MESSAGE WILL NOT BE COLLECTED AND INSERTED IN THE BUG DATABASE. http://nagoya.apache.org/bugzilla/show_bug.cgi?id=10383 Specially crafted GET request causes the answering httpd process and the answering AJP13 processor to hang indefinitely [EMAIL PROTECTED] changed: What|Removed |Added Status|NEW |ASSIGNED --- Additional Comments From [EMAIL PROTECTED] 2002-12-30 15:23 --- Thanks for the excellent bug report and the patch. I have verified that the bug exists. I am looking into the best way to handle exceptions when processing a request with Ajp. -- To unsubscribe, e-mail: mailto:[EMAIL PROTECTED] For additional commands, e-mail: mailto:[EMAIL PROTECTED]
DO NOT REPLY [Bug 10383] - Specially crafted GET request causes the answering httpd process and the answering AJP13 processor to hang indefinitely
DO NOT REPLY TO THIS EMAIL, BUT PLEASE POST YOUR BUG RELATED COMMENTS THROUGH THE WEB INTERFACE AVAILABLE AT http://nagoya.apache.org/bugzilla/show_bug.cgi?id=10383. ANY REPLY MADE TO THIS MESSAGE WILL NOT BE COLLECTED AND INSERTED IN THE BUG DATABASE. http://nagoya.apache.org/bugzilla/show_bug.cgi?id=10383 Specially crafted GET request causes the answering httpd process and the answering AJP13 processor to hang indefinitely [EMAIL PROTECTED] changed: What|Removed |Added Status|ASSIGNED|RESOLVED Resolution||FIXED --- Additional Comments From [EMAIL PROTECTED] 2002-12-30 16:02 --- I have just committed a patch that will return an HTTP status code of 400 - Bad Request when this happens. -- To unsubscribe, e-mail: mailto:[EMAIL PROTECTED] For additional commands, e-mail: mailto:[EMAIL PROTECTED]
DO NOT REPLY [Bug 10383] - Specially crafted GET request causes the answering httpd process and the answering AJP13 processor to hang indefinitely
DO NOT REPLY TO THIS EMAIL, BUT PLEASE POST YOUR BUG RELATED COMMENTS THROUGH THE WEB INTERFACE AVAILABLE AT http://nagoya.apache.org/bugzilla/show_bug.cgi?id=10383. ANY REPLY MADE TO THIS MESSAGE WILL NOT BE COLLECTED AND INSERTED IN THE BUG DATABASE. http://nagoya.apache.org/bugzilla/show_bug.cgi?id=10383 Specially crafted GET request causes the answering httpd process and the answering AJP13 processor to hang indefinitely --- Additional Comments From [EMAIL PROTECTED] 2002-12-29 22:18 --- Hi, meanwhile I found time (OK, quite a long time has passed between now and my original Bug Report :-), but I hoped someone would find a better solution.) to create a workaround patch that prevents a least the hanging of the answering httpd and the answering AJP13 processor (see also attachment): diff -Nru jakarta-tomcat-connectors-4.0.4-src.orig/jk/java/org/apache/ajp/tomcat4/Ajp13Processor.java jakarta-tomcat-connectors-4.0.4-src/jk/java/org/apache/ajp/tomcat4/Ajp13Processor.java --- jakarta-tomcat-connectors-4.0.4-src.orig/jk/java/org/apache/ajp/tomcat4/Ajp13Processor.java 2002-06-11 08:48:08.0 +0200 +++ jakarta-tomcat-connectors-4.0.4-src/jk/java/org/apache/ajp/tomcat4/Ajp13Processor.java 2002-12-29 14:33:56.0 +0100 @@ -468,7 +468,11 @@ logger.log(finished handling request.); } -} catch (Throwable e) { +} catch (IllegalArgumentException e) { +logger.log(process: invoke: IllegalArgumentException: + e.getMessage() + : closing socket); +break; +} + catch (Throwable e) { logger.log(process: invoke, e); } The patch has been made against the tomcat connectors of 4.0.4 as in my original environment of the bug report, but I guess it fits also to the newer versions of 4.0.x or is easy to adjust to them. Ok, what are the effects of this patch: 1. The IllegalArgumentException caused by the wrong cookie will be caught, a short message without the full stack trace will be logged and the while loop starting in line 388 will be left in line 493. 2. Leaving the while loop in line 493 will cause the ajp13 object and thus the connection to mod_jk to be closed by the answering AJP13 processor. 3. mod_jk gets an error reading the reply from the AJP13 processor (see mod_jk.log excerpt below) because the socket has been closed by the AJP13 processor. Thus it tries to contact (via new TCP/IP connections) Tomcat two more times via the same worker to send the request. In a load balanced environment all other workers of the load balanced worker will be tried afterwards for three times. After that mod_jk gives up and Apache sends a code 500 (Internal server error) back to the client. Excerpt from mod_jk.log: [Sun Dec 29 17:17:07 2002] [jk_ajp_common.c (652)]: ajp_connection_tcp_get_message: Error - jk_tcp_socket_recvfull failed [Sun Dec 29 17:17:07 2002] [jk_ajp_common.c (1013)]: Error reading reply [Sun Dec 29 17:17:07 2002] [jk_ajp_common.c (1150)]: In jk_endpoint_t::service, ajp_get_reply failed in send loop 0 [Sun Dec 29 17:17:07 2002] [jk_ajp_common.c (652)]: ajp_connection_tcp_get_message: Error - jk_tcp_socket_recvfull failed [Sun Dec 29 17:17:07 2002] [jk_ajp_common.c (1013)]: Error reading reply [Sun Dec 29 17:17:07 2002] [jk_ajp_common.c (1150)]: In jk_endpoint_t::service, ajp_get_reply failed in send loop 1 [Sun Dec 29 17:17:07 2002] [jk_ajp_common.c (652)]: ajp_connection_tcp_get_message: Error - jk_tcp_socket_recvfull failed [Sun Dec 29 17:17:07 2002] [jk_ajp_common.c (1013)]: Error reading reply [Sun Dec 29 17:17:07 2002] [jk_ajp_common.c (1150)]: In jk_endpoint_t::service, ajp_get_reply failed in send loop 2 [Sun Dec 29 17:17:07 2002] [jk_lb_worker.c (373)]: In jk_endpoint_t::service, No more workers left, can not submit the request [Sun Dec 29 17:17:07 2002] [jk_lb_worker.c (380)]: In jk_endpoint_t::service: NULL Parameters Excerpt from catalina_log: 2002-12-29 17:17:07 Ajp13Processor[7006][4] process: invoke: IllegalArgumentException: Cookie name domain is a reserved token: closing socket 2002-12-29 17:17:07 Ajp13Processor[7006][2] process: invoke: IllegalArgumentException: Cookie name domain is a reserved token: closing socket 2002-12-29 17:17:07 Ajp13Processor[7006][2] process: invoke: IllegalArgumentException: Cookie name domain is a reserved token: closing socket I know that this patch is far from optimal (at least because of the senseless reconnection tries of mod_jk), but it prevents at least the indefinite blocking of resources on Apache and Tomcat side. Thus it helps to prevent a denial of service attack using this bug. As the JK/AJP connector is deprecated and is not used any longer in the 4.1.x series, I guess this patch will not find its way in the CVS, but it may be helpful to people with the same problem who search for a quick and easy fix of this bug without upgrading. The patch
DO NOT REPLY [Bug 10383] - Specially crafted GET request causes the answering httpd process and the answering AJP13 processor to hang indefinitely
DO NOT REPLY TO THIS EMAIL, BUT PLEASE POST YOUR BUG RELATED COMMENTS THROUGH THE WEB INTERFACE AVAILABLE AT http://nagoya.apache.org/bugzilla/show_bug.cgi?id=10383. ANY REPLY MADE TO THIS MESSAGE WILL NOT BE COLLECTED AND INSERTED IN THE BUG DATABASE. http://nagoya.apache.org/bugzilla/show_bug.cgi?id=10383 Specially crafted GET request causes the answering httpd process and the answering AJP13 processor to hang indefinitely --- Additional Comments From [EMAIL PROTECTED] 2002-12-29 22:20 --- Created an attachment (id=4284) Patch to comments from 2002-12-29 22:18 as attachment -- To unsubscribe, e-mail: mailto:[EMAIL PROTECTED] For additional commands, e-mail: mailto:[EMAIL PROTECTED]