Bug 139754

This message reports a DoS issue with mod_perl.

http://mathforum.org/epigone/modperl/spoysamvol/40561DB4.6070409@stason.org

The message is light on details.  It seems that under certain
circumstances, it's possible to provide mod_perl with some input, that
will cause it to crash, and with enough data, one can DoS the web server.


Here is the patch included in the mail (in the event the URL becomes
invalid).


Index: src/modules/perl/modperl_io_apache.c
===================================================================
RCS file: /home/cvs/modperl-2.0/src/modules/perl/modperl_io_apache.c,v
retrieving revision 1.17
diff -u -r1.17 modperl_io_apache.c
--- src/modules/perl/modperl_io_apache.c        4 Mar 2004 06:01:07 -0000 
  1.17
+++ src/modules/perl/modperl_io_apache.c        15 Mar 2004 21:17:57 -0000
@@ -292,8 +292,20 @@

          rc = ap_get_brigade(r->input_filters, bb, AP_MODE_READBYTES,
                              APR_BLOCK_READ, len);
-        if (rc != APR_SUCCESS) {
+        if (rc != APR_SUCCESS) {
              char *error;
+
+            /* EOF is not really an error. A possible reason for
+             * getting EOF: if EOS came in the same bb with data, or
+             * more data than available was asked for, the fact that
+             * EOS has passed through wasn't stored
+             * anywhere. Therefore a request to get another bb after
+             * EOS was seen, may result in a valid EOF response */
+            if (rc == APR_EOF) {
+                MP_TRACE_o(MP_FUNC, "wanted %db, read EOF", wanted);
+                return 0;
+            }
+
              /* if we fail here, we want to just return and stop trying
               * to read data from the client.
               */
@@ -350,7 +362,7 @@

          /* XXX: what happens if the downstream filter returns more
           * data than the caller has asked for? We can't return more
-         * data that requested, so it needs to be stored somewhere and
+         * data than requested, so it needs to be stored somewhere and
           * dealt with on the subsequent calls to this function. or may
           * be we should just assert, blaming a bad filter. at the
           * moment I couldn't find a spec telling whether it's wrong