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
Can you please check if the following patch fixes this issue?
Index: server/protocol.c
===================================================================
--- server/protocol.c.orig
+++ server/protocol.c
@@ -659,6 +659,7 @@ static int read_request_line(request_rec
r->hostname = NULL;
r->status = HTTP_BAD_REQUEST;
r->uri = apr_pstrdup(r->pool, uri);
+ return 0;
}
if (ll[0]) {
@@ -913,9 +914,15 @@ request_rec *ap_read_request(conn_rec *c
/* Get the request... */
if (!read_request_line(r, tmp_bb)) {
- if (r->status == HTTP_REQUEST_URI_TOO_LARGE) {
- ap_log_rerror(APLOG_MARK, APLOG_ERR, 0, r,
+ if (r->status == HTTP_REQUEST_URI_TOO_LARGE
+ || r->status == HTTP_BAD_REQUEST) {
+ if (r->status == HTTP_REQUEST_URI_TOO_LARGE) {
+ ap_log_rerror(APLOG_MARK, APLOG_ERR, 0, r,
"request failed: URI too long (longer than %d)", r->server->limit_req_line);
+ } else if (r->method == NULL) {
+ ap_log_rerror(APLOG_MARK, APLOG_ERR, 0, r,
+ "request failed: invalid characters in URI");
+ }
ap_send_error_response(r, 0);
ap_update_child_status(conn->sbh, SERVER_BUSY_LOG, r);
ap_run_log_transaction(r);
