Additional problems were discovered in the httpd fix for CVE-2011-3368 - a reverse proxy bypass flaw - tracked via bug #740045. Upstream mailing list post identifies following request forms, which are not handled correctly: GET @localhost::8880 HTTP/1.0\r\n\r\n GET qualys:@qqq.qq.qualys.com HTTP/1.0\r\n\r\n Reference: http://thread.gmane.org/gmane.comp.apache.devel/46440
External References: https://community.qualys.com/blogs/securitylabs/2011/11/23/apache-reverse-proxy-bypass-issue
Well, If I try this with a similar setup and post the request forms, I always get an error stating that the request-URI is invalid: [Mon Nov 28 13:57:34 2011] [error] [client a.b.c.d] invalid request-URI @localhost::8080 Am I doing something wrong :) ? I'm using the latest Redhat httpd rpm. Kind regards Werner
This works fine: : httpd-2.2.3 10:24#; fp;echo -e "GET / HTTP/1.0\r\n" |nc a.b.c.d 80 HTTP/1.1 200 OK but this command generates the bad request error. : httpd-2.2.3 10:26#; fp;echo -e "GET @localhost::80 HTTP/1.0\r\n" |nc a.b.c.d 80 HTTP/1.1 400 Bad Request tcpdump -A 'host x and tcp port 80 and (((ip[2:2] - ((ip[0]&0xf)<<2)) - ((tcp[12]&0xf0)>>2)) != 0)' shows E..RDE@.>....: g.:...'.Pd4..........>...... "#..L...GET @localhost::80 HTTP/1.0 E....<@.@..[.:...: g.P.'....d4......h...... L..."#..HTTP/1.1 400 Bad Request So my proxy setup does not seem to vulnerable?
The scheme trick does not work against httpd in Red Hat Enterprise Linux 4 and 5, due to the difference in apr-util's apr_uri_parse() implementation. Newer apr-util versions include the following change: http://svn.apache.org/viewvc?view=revision&revision=594624 to allow URIs as: scheme:rest, where rest does not need to start with "//". In that case, rest is parsed as path component of the URI, and can possibly start with ':' or '@', which allow redirecting request to a different port on the configured remote host or different remote host as was demonstrated. Older versions require scheme to be followed by "://" and the part following "://" is parsed as authority (host + optional port and username/password) followed by path. That code path does not allow paths starting with ':' or '@'.
(In reply to comment #8) > Older versions require scheme to be followed by "://" and the part following > "://" is parsed as authority (host + optional port and username/password) > followed by path. That code path does not allow paths starting with > ':' or '@'. Let's extend this explanation a bit to make it easier to understand. The original CVE-2011-3368 fix added following check to reject invalid URIs: + if (r->method_number != M_CONNECT + && !r->parsed_uri.scheme + && uri[0] != '/' + && !(uri[0] == '*' && uri[1] == '\0')) { The aim is to reject requests which contain path that does not start with /. There are exceptions like URI "*" or any URI that contains scheme part. In recent apr-util, it is easy to provide URI which is parsed by apr_uri_parse() to non-NULL scheme and path not starting with / (scheme: @localhost, path: :8880 and scheme: qualys, path: @qqq.qq.qualys.com). In older versions, when apr_uri_parse() returns non-NULL scheme, path is always either NULL or starting with /, which is safe.
Proposed upstream fix: http://thread.gmane.org/gmane.comp.apache.devel/47061 originally proposed in the discussion thread linked in comment #0: http://thread.gmane.org/gmane.comp.apache.devel/46440/focus=46742
(In reply to comment #10) > Proposed upstream fix: > http://thread.gmane.org/gmane.comp.apache.devel/47061 In trunk and 2.4.x now: http://svn.apache.org/viewvc?view=revision&revision=1233604 http://svn.apache.org/viewvc?view=revision&revision=1233619
Fixed in 2.2.x now too, queued for 2.2.22 release: http://svn.apache.org/viewvc?view=revision&revision=1235443
Statement: This issue did not affect the versions of httpd as shipped with Red Hat Enterprise Linux 4 and 5 due to differences in apr-util's apr_uri_parse() implementation.
This issue has been addressed in following products: Red Hat Enterprise Linux 6 Via RHSA-2012:0128 https://rhn.redhat.com/errata/RHSA-2012-0128.html