Re: [PATCH] CAN-2004-0942 fix

[Bill Stoddard]

Joe Orton wrote:
On Wed, Nov 03, 2004 at 01:39:20PM -0500, Bill Stoddard wrote:
Joe Orton wrote:

+/* Now NUL-terminate the string at the end of the line; 
+ * if the last-but-one character is a CR, terminate there */
+if (last_char > *s && last_char[-1] == APR_ASCII_CR) {
last_char[-1]... yack, that's just nasty syntax if you ask me.

Succinct and easier to parse than *(last_char - 1) if you ask me...
Kept getting interrupted, but +1 for the patch. I don't personally care for the last_char[-1] syntax, but 
that's just my preference.

Bill

Re: [PATCH] CAN-2004-0942 fix

[Joe Orton]

On Wed, Nov 03, 2004 at 01:39:20PM -0500, Bill Stoddard wrote:
> Joe Orton wrote:
> 
> >+/* Now NUL-terminate the string at the end of the line; 
> >+ * if the last-but-one character is a CR, terminate there */
> >+if (last_char > *s && last_char[-1] == APR_ASCII_CR) {
> 
> last_char[-1]... yack, that's just nasty syntax if you ask me.

Succinct and easier to parse than *(last_char - 1) if you ask me...

Re: [PATCH] CAN-2004-0942 fix

[Bill Stoddard]

Joe Orton wrote:
+/* Now NUL-terminate the string at the end of the line; 
+ * if the last-but-one character is a CR, terminate there */
+if (last_char > *s && last_char[-1] == APR_ASCII_CR) {
last_char[-1]... yack, that's just nasty syntax if you ask me.
Bill

Re: [PATCH] CAN-2004-0942 fix

[=?ISO-8859-15?Q?Andr=E9?= Malo]

* 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: