Date: Thu, 15 Jan 2015 14:23:25 -0500 (EST) From: cve-assign@...re.org To: vkaigoro@...hat.com Cc: cve-assign@...re.org, oss-security@...ts.openwall.com Subject: Re: CVE request: httpd: IP address spoofing in mod_remoteip -----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 > Can a CVE be assigned to this please? Our interpretation is that the bug reports are actually describing correct and intended behavior. Similarly, the patch seems to break some realistic uses of the mod_remoteip module. The patch is only useful for sites that have chosen to list a trusted proxy that isn't actually trusted. For example, http://mail-archives.apache.org/mod_mbox/httpd-users/201210.mbox/%3CCAHa2qaJSW7Hvk68grWMbbiFSA=zAxQ1nr_-A-K-pDWbAB0Gd1Q@...l.gmail.com%3E says: 1. Client(184.108.40.206) send a request with spoofed X-Forwarded-For header. X-Forwarded-For: 220.127.116.11 2. Proxy/Load Balancer(10.0.0.1) append the client IP address to existing X-Forwarded-For header. X-Forwarded-For: 18.104.22.168, 22.214.171.124 3. Apache server receive forwarded request. (httpd.conf) RemoteIPHeader X-Forwarded-For RemoteIPTrustedProxy 10.0.0.0/8 I expected that mod_remoteip would override client IP with 126.96.36.199 because 10.0.0.1 is trusted and 188.8.131.52 is not trusted. Actually, client IP was overridden with 184.108.40.206. Here, 10.0.0.1 is trusted to present ANY public IP address, including both 220.127.116.11 and 18.104.22.168. (10.0.0.1 is NOT, for example, trusted to present a private IP address such as 192.168.0.2.) The documentation says "It is critical to only enable this behavior from intermediate hosts (proxies, etc) which are trusted by this server, since it is trivial for the remote useragent to impersonate another useragent." In other words, the operator of the Apache HTTP Server has delegated to 10.0.0.1 the responsibility for sending an X-Forwarded-For header that is valid according to the rule set established by the 10.0.0.1 configuration. Only the 10.0.0.1 configuration can determine whether 22.214.171.124 is trusted to send an "X-Forwarded-For: 126.96.36.199" header. The bug reports seem to envision a world in which the Apache HTTP Server configuration has information about the proxy-trust rule sets of the entire outside world. The documentation does not state that it should have that information, and (from a network-architecture perspective) it really wouldn't make much sense for it to have that information. The documentation says "Processing halts when a given useragent IP address is not trusted to present the preceding IP address." This is perhaps confusing because the available directives don't provide any way to express a rule about whether a specific N-hops-away external IP address is allowed to present any specific (N+1)-hops-away external IP address. The directives are only about the Apache HTTP Server's trust of 1-hop-away external IP addresses. It seems plausible that the documentation means that these two types of halts were thought to be desirable: 1. If the Apache HTTP Server is communicating directly with a host, and that host is specified in neither a RemoteIPTrustedProxy nor a RemoteIPInternalProxy directive, then processing halts at the right-most IP address in the X-Forwarded-For header. Here, the goal of the halt is to reject an unauthorized proxy. 2. If the Apache HTTP Server is communicating directly with a host, and that host is specified in a RemoteIPTrustedProxy directive but not in a RemoteIPInternalProxy directive, then processing halts at the right-most private IP address in the X-Forwarded-For header. For example: X-Forwarded-For: 188.8.131.52, 184.108.40.206, 192.168.0.2, 220.127.116.11, 18.104.22.168 halts at 192.168.0.2. From a network-architecture perspective, this seems to make perfect sense because the meaning of 192.168.0.2 with respect to host 22.214.171.124 can be completely different from the meaning of 192.168.0.2 on the intranet of the Apache HTTP Server. Here, the goal of the halt is to reject an out-of-context intranet address. In other words, we believe that the bug report's expectation of "mod_remoteip would override client IP with 126.96.36.199 because 10.0.0.1 is trusted and 188.8.131.52 is not trusted" is false. From the perspective of directly incoming IP packets to the Apache HTTP Server, 184.108.40.206 is neither trusted nor untrusted. A 220.127.116.11 trust decision is outside the scope of what the Apache HTTP Server can or should do. The 18.104.22.168 trust decision belongs exclusively to the operator of 10.0.0.1. If all of this is wrong, and mod_remoteip actually wanted to have complete information about the proxy-trust rule sets of the outside world, then security@...che.org (see the http://www.apache.org/security/committers.html page) can assign a CVE ID. - -- CVE assignment team, MITRE CVE Numbering Authority M/S M300 202 Burlington Road, Bedford, MA 01730 USA [ PGP key available through http://cve.mitre.org/cve/request_id.html ] -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.4.14 (SunOS) iQEcBAEBAgAGBQJUuBLMAAoJEKllVAevmvms1/gIAKYbRVPyqAt50iLQUfR28cwg JEtszo89A7vzCyh3JAPiCDVO9AAIBKRseldKLH6z/SEjVbmqrteEWmIR1gf2vaEO 89JfxRupq2fSypltI8ZfP3qISUyroCiaU596x8av0XjuEGpCX10n+hqMJ6bcLf39 Pykp8/xOqOQ5xLqTYu27Os8OL+av2aKT3EpT4l4PnRvjitLk0sCcQLrEtbu8Mn6N Vc6KWAVm2Vzmqdf1DlhirGFbae5xAv0cqTe+nRel3nqTmHnD8M73qTEdo2wVyAYj kTgSSoebp6j6MeA/OIAO9hbg7x3SvV2OOKy2z3T5A+K+7Ri9vblOKGllDtWwNd0= =oDAH -----END PGP SIGNATURE-----
Powered by blists - more mailing lists
Please check out the Open Source Software Security Wiki, which is counterpart to this mailing list.
Powered by Openwall GNU/*/Linux - Powered by OpenVZ