Bug 139756 - mod_perl DoS
Summary: mod_perl DoS
Status: CLOSED NOTABUG
Alias: None
Product: Fedora
Classification: Fedora
Component: mod_perl (Show other bugs)
(Show other bugs)
Version: 3
Hardware: All Linux
medium
low
Target Milestone: ---
Assignee: Joe Orton
QA Contact: David Lawrence
URL:
Whiteboard: impact=low,public=20040315
Keywords: Security
Depends On:
Blocks:
TreeView+ depends on / blocked
 
Reported: 2004-11-17 21:11 UTC by Josh Bressers
Modified: 2007-11-30 22:10 UTC (History)
1 user (show)

Fixed In Version:
Doc Type: Bug Fix
Doc Text:
Story Points: ---
Clone Of:
Environment:
Last Closed: 2005-04-22 13:55:49 UTC
Type: ---
Regression: ---
Mount Type: ---
Documentation: ---
CRM:
Verified Versions:
Category: ---
oVirt Team: ---
RHEL 7.3 requirements from Atomic Host:
Cloudforms Team: ---


Attachments (Terms of Use)

Description Josh Bressers 2004-11-17 21:11:26 UTC
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

Comment 1 Josh Bressers 2004-11-17 21:13:22 UTC
This should also affect FC2.

Comment 2 Joe Orton 2004-12-15 15:16:06 UTC
FC2 bug 139653 is this same issue.  I just pinged upstream again now
and also the user to try and discover the repro case.

Comment 3 Joe Orton 2005-04-22 13:55:49 UTC
Per bug 139653 - the spin can only occur if the script ignores the error
returned by mod_perl, so I can't see a bug here.


Note You need to log in before you can comment on or make changes to this bug.