[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Message-Id: <20150115192325.E5F316C0009@smtpvmsrv1.mitre.org>
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@mail.gmail.com%3E
says:
1. Client(1.1.1.1) send a request with spoofed X-Forwarded-For header.
X-Forwarded-For: 2.2.2.2
2. Proxy/Load Balancer(10.0.0.1) append the client IP address to
existing X-Forwarded-For header.
X-Forwarded-For: 2.2.2.2, 1.1.1.1
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 1.1.1.1
because 10.0.0.1 is trusted
and 1.1.1.1 is not trusted. Actually, client IP was overridden with 2.2.2.2.
Here, 10.0.0.1 is trusted to present ANY public IP address, including
both 1.1.1.1 and 2.2.2.2. (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
1.1.1.1 is trusted to send an "X-Forwarded-For: 2.2.2.2" 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: 4.4.4.4, 3.3.3.3, 192.168.0.2, 2.2.2.2, 1.1.1.1
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 2.2.2.2 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 1.1.1.1 because 10.0.0.1
is trusted and 1.1.1.1 is not trusted" is false. From the perspective
of directly incoming IP packets to the Apache HTTP Server, 1.1.1.1 is
neither trusted nor untrusted. A 1.1.1.1 trust decision is outside the
scope of what the Apache HTTP Server can or should do. The 1.1.1.1
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.
Confused about mailing lists and their use?
Read about mailing lists on Wikipedia
and check out these
guidelines on proper formatting of your messages.
