* Joe Orton <[EMAIL PROTECTED]> wrote: > http://lists.netsys.com/pipermail/full-disclosure/2004-November/028248.html > > describes a memory consumption DoS against 2.0, which has been assigned > CVE CAN-2004-0942; in the case given, ap_rgetline_core will allocate > approx N * 3 bytes to hold the line, but then trim all but one byte of > trailing whitespace, so the field length limit is not correctly > enforced. > > The simplest fix is to move the trailing-whitespace-trimming logic out > of ap_rgetline_core into ap_get_mime_headers_core, patch below does that > and also simplifies the over-complicated logic for stripping LWS between > field-name and colon. > > Looking at the other places where ap_rgetline is used: in the proxy, > ap_proxy_read_headers already strips trailing whitespace, it doesn't > really matter to ap_proxy_http_process_response whether trailing > whitespace is stripped on the status-line. > > In protocol.c, read_request_line will use the sscanf path rather than > the fast-path to handle status-lines with trailing whitespace, which is > OK too.
+1 to the solution and the patch (Reviewed and tested). nd -- "Das Verhalten von Gates hatte mir bewiesen, dass ich auf ihn und seine beiden Gefährten nicht zu zählen brauchte" -- Karl May, "Winnetou III" Im Westen was neues: <http://pub.perlig.de/books.html#apache2>
