Bug 139754 - mod_perl DoS
Summary: mod_perl DoS
Status: CLOSED NOTABUG
Alias: None
Product: Red Hat Enterprise Linux 3
Classification: Red Hat
Component: mod_perl (Show other bugs)
(Show other bugs)
Version: 3.0
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:08 UTC by Josh Bressers
Modified: 2007-11-30 22:07 UTC (History)
0 users

Fixed In Version:
Doc Type: Bug Fix
Doc Text:
Story Points: ---
Clone Of:
Environment:
Last Closed: 2005-04-22 13:56:23 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:08:19 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:09:45 UTC
This issue probably also affects RHEL2.1.

Comment 2 Josh Bressers 2004-11-17 21:10:28 UTC
We should also ensure that this fix makes it into RHEL4.

Comment 3 Joe Orton 2004-11-19 10:01:25 UTC
Issue is specific to mod_perl-2.0 (aka 1.99) code and hence doesn't
affect RHEL2.1, and was introduced in mod_perl-1.99_10 and hence
doesn't  affect RHEL3's mod_perl-1.99_09.

Comment 4 Joe Orton 2005-04-22 13:56:23 UTC
Marking NOTABUG per comment #3 and bug 139756.



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