Bug 824797
| Summary: | No longer supports rewriting HTTP CONNECT | ||||||
|---|---|---|---|---|---|---|---|
| Product: | [Fedora] Fedora | Reporter: | Gordon Russell <g.russell> | ||||
| Component: | httpd | Assignee: | Joe Orton <jorton> | ||||
| Status: | CLOSED WONTFIX | QA Contact: | Fedora Extras Quality Assurance <extras-qa> | ||||
| Severity: | medium | Docs Contact: | |||||
| Priority: | unspecified | ||||||
| Version: | 15 | CC: | jkaluza, jorton, pahan | ||||
| Target Milestone: | --- | ||||||
| Target Release: | --- | ||||||
| Hardware: | x86_64 | ||||||
| OS: | Linux | ||||||
| Whiteboard: | |||||||
| Fixed In Version: | Doc Type: | Bug Fix | |||||
| Doc Text: | Story Points: | --- | |||||
| Clone Of: | Environment: | ||||||
| Last Closed: | 2012-08-07 16:38:11 UTC | Type: | Bug | ||||
| Regression: | --- | Mount Type: | --- | ||||
| Documentation: | --- | CRM: | |||||
| Verified Versions: | Category: | --- | |||||
| oVirt Team: | --- | RHEL 7.3 requirements from Atomic Host: | |||||
| Cloudforms Team: | --- | Target Upstream Version: | |||||
| Embargoed: | |||||||
| Attachments: |
|
||||||
The following patch fixes the problem for me. It also gives some logging for future users want to debug similar issues. I will submit it to the apache tracker.
-----
diff -Npru httpd-2.2.22.orig/modules/mappers/mod_rewrite.c httpd-2.2.22/modules/
mappers/mod_rewrite.c
--- httpd-2.2.22.orig/modules/mappers/mod_rewrite.c 2012-01-24 19:39:31.0000
00000 +0000
+++ httpd-2.2.22/modules/mappers/mod_rewrite.c 2012-05-24 14:47:49.949153810 +0
100
@@ -4267,10 +4267,14 @@ static int hook_uri2file(request_rec *r)
}
if ((r->unparsed_uri[0] == '*' && r->unparsed_uri[1] == '\0')
- || !r->uri || r->uri[0] != '/') {
+ || !r->uri ||
+ (r->uri[0] != '/' && r->method_number != M_CONNECT)) {
+ rewritelog((r, 2, NULL, "uri %s is considered a security risk",
+ r->uri));
return DECLINED;
}
+
/*
* add the SCRIPT_URL variable to the env. this is a bit complicated
* due to the fact that apache uses subrequests and internal redirects
Sorry to keep going on...
Looking at my patch maybe the rewritelog line needs to be protected against r->uri being null? Probably someone with security knowledge should check this!
So maybe (again forwarded to apache tracker):
diff -Npru httpd-2.2.22.orig/modules/mappers/mod_rewrite.c httpd-2.2.22/modules/
mappers/mod_rewrite.c
--- httpd-2.2.22.orig/modules/mappers/mod_rewrite.c 2012-01-24 19:39:31.0000
00000 +0000
+++ httpd-2.2.22/modules/mappers/mod_rewrite.c 2012-05-24 14:47:49.949153810 +0
100
@@ -4267,10 +4267,14 @@ static int hook_uri2file(request_rec *r)
}
if ((r->unparsed_uri[0] == '*' && r->unparsed_uri[1] == '\0')
- || !r->uri || r->uri[0] != '/') {
+ || !r->uri ||
+ (r->uri[0] != '/' && r->method_number != M_CONNECT)) {
+ rewritelog((r, 2, NULL, "uri %s is considered a security risk",
+ r->uri ? r->uri : "<null>"));
return DECLINED;
}
+
/*
* add the SCRIPT_URL variable to the env. this is a bit complicated
* due to the fact that apache uses subrequests and internal redirects
Created attachment 587335 [details] Patch v2 for CVE-2011-4317 effecting only rewriterule proxy Submitted a patch to apache to re-fix the CVE problem which caused this bug. Patch restricts URI check to rewriterule [P], and if the URI check fails does FORBIDDEN rather than fall through mod_rewrite (which in my case disabled request security as this was based on mod_rewrite). Could someone check this patch to see if the CVE report is still fixed with this new patch? Assuming the patch is ok then could someone on the apache devel list steer the change through their process? Thanks. This message is a notice that Fedora 15 is now at end of life. Fedora has stopped maintaining and issuing updates for Fedora 15. It is Fedora's policy to close all bug reports from releases that are no longer maintained. At this time, all open bugs with a Fedora 'version' of '15' have been closed as WONTFIX. (Please note: Our normal process is to give advanced warning of this occurring, but we forgot to do that. A thousand apologies.) Package Maintainer: If you wish for this bug to remain open because you plan to fix it in a currently maintained version, feel free to reopen this bug and simply change the 'version' to a later Fedora version. Bug Reporter: Thank you for reporting this issue and we are sorry that we were unable to fix it before Fedora 15 reached end of life. If you would still like to see this bug fixed and are able to reproduce it against a later version of Fedora, you are encouraged to click on "Clone This Bug" (top right of this page) and open it against that version of Fedora. Although we aim to fix as many bugs as possible during every release's lifetime, sometimes those efforts are overtaken by events. Often a more recent Fedora release includes newer upstream software that fixes bugs or makes them obsolete. The process we are following is described here: http://fedoraproject.org/wiki/BugZappers/HouseKeeping |
Description of problem: I moved from 2.2.21 to 2.2.22 on Fedora 15, and my mod_rewrite commands are no longer parsed when the request is the CONNECT method. It used to be possible and reasonably documented to be able to do rewrites like: RewriteCond %{REQUEST_METHOD} ^connect$ [NC] RewriteCond %{THE_REQUEST} !^connect\ tunnel-([^\ ]+)\.proxymachine\.net:([0-9]+)\ .*$ [NC] RewriteRule ^(.*)$ $1 [F,L] I use code like this to rewrite the uri to point to the tunnel endpoint from a RewriteMap file, and this has worked well for a few years. Even at logging level 9 nothing it produced in 2.2.22. Reverting the mod_rewrite module to 2.2.21 fixes the issue. Although not tested, I suspect httpd-2.2.22/modules/mappers/mod_rewrite.c at line 4268, which returns DECLINED if the uri[0] is not "/". However CONNECT is more likely to have the format "CONNECT the.machine.com:6000", and this contains no "/" characters. In fact attempting a CONNECT with a "/" gives an error very early on in the parse tree. I think the " r->uri[0] != '/' " test should have been guarded with a " r->method_number == M_CONNECT " test, but to be honest I have not tested this except in my head. Bug raised with apache, #53286 Version-Release number of selected component (if applicable): 2.2.22 How reproducible: 100% Steps to Reproduce: 1. Set mod_rewrite logging to 9 and include a rewrite rule which should be parsed in the request. Configure httpd to support proxying. 2. Send a CONNECT request 3. See if any output appears in the rewrite log Actual results: Nothing is logged Expected results: Rewrite is logged and rules are parsed Additional info: