You are viewing a plain text version of this content. The canonical link for it is here.
Posted to dev@httpd.apache.org by Marcus Meissner <me...@suse.de> on 2011/10/25 14:29:00 UTC
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
RE: CVE-2011-3368 not fully fixed?
Posted by "Plüm, Rüdiger, VF-Group" <ru...@vodafone.com>.
> -----Original Message-----
> From: "Plüm, Rüdiger, VF-Group" [mailto:ruediger.pluem@vodafone.com]
> Sent: Dienstag, 25. Oktober 2011 18:48
> To: dev@httpd.apache.org
> Subject: RE: CVE-2011-3368 not fully fixed?
>
>
>
> > -----Original Message-----
> > From: William A. Rowe Jr. [mailto:wrowe@rowe-clan.net]
> > Sent: Dienstag, 25. Oktober 2011 18:44
> > To: dev@httpd.apache.org
> > Subject: Re: CVE-2011-3368 not fully fixed?
> >
> > On 10/25/2011 11:21 AM, "Plüm, Rüdiger, VF-Group" wrote:
> > > I did some further analysis. While the patch for trunk is
> still fine
> > > as it shortens the path for bailing out the behaviour was
> > already correct
> > > with trunk and 2.2.21. So the HTTP/0.9 behaviour you see
> > does NOT happen with
> > > 2.2.x >= 2.2.18 (plus patch) and trunk. You are affected by
> > an old logic that
> > > was changed in r1100200 and hence changed since 2.2.18.
> >
> > Should the contents of www.a.o/dist/httpd/patches/apply_to_2.2...
> > be updated?
> >
> >
>
> No. We only supply this patch for 2.2.21 and everything later
> then 2.2.18
> does not show the behaviour mentioned here.
> Or to put it the other way around 2.2.21 plus the patch we
> supply behaves well
> with HTTP/0.9 requests.
Or further put: My patch on trunk is an optimization, but not a change in
behaviour. I do not even consider it worth backporting to 2.2.x.
Regards
Rüdiger
RE: CVE-2011-3368 not fully fixed?
Posted by "Plüm, Rüdiger, VF-Group" <ru...@vodafone.com>.
> -----Original Message-----
> From: William A. Rowe Jr. [mailto:wrowe@rowe-clan.net]
> Sent: Dienstag, 25. Oktober 2011 18:44
> To: dev@httpd.apache.org
> Subject: Re: CVE-2011-3368 not fully fixed?
>
> On 10/25/2011 11:21 AM, "Plüm, Rüdiger, VF-Group" wrote:
> > I did some further analysis. While the patch for trunk is still fine
> > as it shortens the path for bailing out the behaviour was
> already correct
> > with trunk and 2.2.21. So the HTTP/0.9 behaviour you see
> does NOT happen with
> > 2.2.x >= 2.2.18 (plus patch) and trunk. You are affected by
> an old logic that
> > was changed in r1100200 and hence changed since 2.2.18.
>
> Should the contents of www.a.o/dist/httpd/patches/apply_to_2.2...
> be updated?
>
>
No. We only supply this patch for 2.2.21 and everything later then 2.2.18
does not show the behaviour mentioned here.
Or to put it the other way around 2.2.21 plus the patch we supply behaves well
with HTTP/0.9 requests.
Regards
Rüdiger
Re: CVE-2011-3368 not fully fixed?
Posted by "William A. Rowe Jr." <wr...@rowe-clan.net>.
On 10/25/2011 11:21 AM, "Plüm, Rüdiger, VF-Group" wrote:
> I did some further analysis. While the patch for trunk is still fine
> as it shortens the path for bailing out the behaviour was already correct
> with trunk and 2.2.21. So the HTTP/0.9 behaviour you see does NOT happen with
> 2.2.x >= 2.2.18 (plus patch) and trunk. You are affected by an old logic that
> was changed in r1100200 and hence changed since 2.2.18.
Should the contents of www.a.o/dist/httpd/patches/apply_to_2.2...
be updated?
RE: CVE-2011-3368 not fully fixed?
Posted by "Plüm, Rüdiger, VF-Group" <ru...@vodafone.com>.
I did some further analysis. While the patch for trunk is still fine
as it shortens the path for bailing out the behaviour was already correct
with trunk and 2.2.21. So the HTTP/0.9 behaviour you see does NOT happen with
2.2.x >= 2.2.18 (plus patch) and trunk. You are affected by an old logic that
was changed in r1100200 and hence changed since 2.2.18.
Regards
Rüdiger
> -----Original Message-----
> From: "Plüm, Rüdiger, VF-Group" [mailto:ruediger.pluem@vodafone.com]
> Sent: Dienstag, 25. Oktober 2011 17:58
> To: dev@httpd.apache.org
> Subject: RE: CVE-2011-3368 not fully fixed?
>
> Thanks for testing. Applied to trunk as r1188745.
>
> Regards
>
> Rüdiger
>
> > -----Original Message-----
> > From: Marcus Meissner [mailto:meissner@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:meissner@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
> >
>
RE: CVE-2011-3368 not fully fixed?
Posted by "Plüm, Rüdiger, VF-Group" <ru...@vodafone.com>.
Thanks for testing. Applied to trunk as r1188745.
Regards
Rüdiger
> -----Original Message-----
> From: Marcus Meissner [mailto:meissner@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:meissner@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
>
Re: CVE-2011-3368 not fully fixed?
Posted by Marcus Meissner <me...@suse.de>.
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:meissner@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
RE: CVE-2011-3368 not fully fixed?
Posted by "Plüm, Rüdiger, VF-Group" <ru...@vodafone.com>.
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:meissner@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
>