DO NOT REPLY [Bug 10383] - Specially crafted GET request causes the answering httpd process and the answering AJP13 processor to hang indefinitely

2003-09-19 Thread bugzilla
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

2003-01-04 Thread bugzilla
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

2003-01-04 Thread Sean Reilly
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

2002-12-30 Thread bugzilla
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

2002-12-30 Thread bugzilla
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

2002-12-29 Thread bugzilla
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

2002-12-29 Thread bugzilla
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]