Thanks for testing. Applied to trunk as r1188745. Regards
Rüdiger > -----Original Message----- > From: Marcus Meissner [mailto:meiss...@suse.de] > Sent: Dienstag, 25. Oktober 2011 17:48 > To: dev@httpd.apache.org > Subject: Re: CVE-2011-3368 not fully fixed? > > Hi Rüdiger, > > I ported your patch to our 2.2.12 codebase (attached) and my testcase > now correctly reports a 400 from the testserver when > doing > GET @www.suse.de/foo.png > as request. > > Ciao, Marcus > > On Tue, Oct 25, 2011 at 02:49:08PM +0200, "Plüm, Rüdiger, > VF-Group" wrote: > > Can you please check if the following patch fixes this issue? > > > > Index: protocol.c > > =================================================================== > > --- protocol.c (revision 1181036) > > +++ protocol.c (working copy) > > @@ -672,6 +672,7 @@ > > r->hostname = NULL; > > r->status = HTTP_BAD_REQUEST; > > r->uri = apr_pstrdup(r->pool, uri); > > + return 0; > > } > > > > if (ll[0]) { > > @@ -960,13 +961,13 @@ > > if (!read_request_line(r, tmp_bb)) { > > if (r->status == HTTP_REQUEST_URI_TOO_LARGE > > || r->status == HTTP_BAD_REQUEST) { > > - if (r->status == HTTP_BAD_REQUEST) { > > + if (r->status == HTTP_REQUEST_URI_TOO_LARGE) { > > ap_log_rerror(APLOG_MARK, APLOG_ERR, 0, r, > > - "request failed: invalid > characters in URI"); > > + "request failed: URI too > long (longer than %d)", r->server->limit_req_line); > > } > > - else { > > + else if (r->method == NULL) { > > ap_log_rerror(APLOG_MARK, APLOG_ERR, 0, r, > > - "request failed: URI too > long (longer than %d)", r->server->limit_req_line); > > + "request failed: invalid > characters in URI"); > > } > > ap_send_error_response(r, 0); > > ap_update_child_status(conn->sbh, SERVER_BUSY_LOG, r); > > > > Regards > > > > Rüdiger > > > > > -----Original Message----- > > > From: Marcus Meissner [mailto:meiss...@suse.de] > > > Sent: Dienstag, 25. Oktober 2011 14:29 > > > To: dev@httpd.apache.org > > > Subject: CVE-2011-3368 not fully fixed? > > > > > > Hi, > > > > > > I probably have overlooked something, but while QAing our > > > Apache (2.2.12 based) > > > updates it seems CVE-2011-3368 is not fully fixed by the > > > patch referenced. > > > > > > With the RewriteRule within the <VirtualHost *:80> section, > > > RewriteEngine on > > > RewriteRule (.*)\.(ico|jpg|gif|png) http://leo.suse.de$1.$2 [P] > > > > > > > > > $ telnet teshost 80 > > > GET @www.suse.de/foo.png > > > ...gives me the 404 page of www.suse.de, which is not intended.... > > > > > > I get in the error log: > > > [Tue Oct 25 14:10:50 2011] [error] [client 10.10.0.233] > > > invalid request-URI @www.suse.de/foo.png > > > and in access.log > > > 10.10.0.233 - - [25/Oct/2011:14:10:50 +0200] "GET > > > @www.suse.de/foo.png" 404 16006 "-" "-" > > > > > > which seems to me like it is half working. > > > The error.log has the invalid request-URI message from the > > > patched part > > > of the code, but the 404 is from www.suse.de/foo.png. > > > > > > > > > => I think the 0.9 protocol method is not falling out of the > > > uri handling correctly. > > > > > > It seems on reading ap_read_request() the 0.9 "assbackwards" > > > case handling > > > does not error out on r->status set but proceeds and sets > > > r->status to HTTP_OK and > > > goes on. > > > > > > Any ideas? Am I doing stuff wrong? > > > > > > Ciao, Marcus > > > > > > > -- > Working, but not speaking, for the following german company: > SUSE LINUX Products GmbH, HRB 16746 (AG Nuernberg) > Geschaeftsfuehrer: Jeff Hawn, Jennifer Guild, Felix Imendoerffer >
