[
https://issues.apache.org/jira/browse/TS-2954?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=14079318#comment-14079318
]
Susan Hinrichs edited comment on TS-2954 at 7/30/14 2:32 PM:
-------------------------------------------------------------
The problem is that I didn't define what the new attributes for
proxy.config.http.use_client_target_addr. The other problem is that my brain
doesn't work so well until after the 5th cup of coffee so I just noticed your
setting now.
proxy.config.http.use_client_target_addr = 0 - Means ignore the client used
address and rely on the proxy's DNS resolution of the host field (behavior
unchanged)
proxy.config.http.use_client_target_addr = 1 - Means use the client used
address, but do not cache if the client used address does not match one of the
proxy's DNS resolved addresses
proxy.config.http.use_client_target_addr = 2 - Means the same as 1 in previous
builds. Use the client used address. Cache in any case. Do not validate
against the proxy's DNS resolved addresses.
Originally I had proposed putting the new behavior on 2, but after talking with
Alan, we decided it would be safer to change the behavior of the already
deployed setting. Folks who really want to live dangerously can change the
setting to 2. By default deployments will gain the security improvement.
So your tests with proxy.config.http.use_client_target_addr = 2 are working as
designed. Sorry for not clarifying earlier. Could you give it a try with
proxy.config.http.use_client_target_addr = 1. I did your experiment and things
worked as I would expect.
The log message "(http_trans) [OSDNSLookup] DNS lookup for O.S. successful IP:
91.239.13.61" is a bit confusing. It is printing the IP address that has be
calculated for the OS regardless of whether a DNS lookup has been done or not.
You should be seeing a log message like "(http_trans) [is_response_cacheable]
Lookup not validated. Possible DNS cache poison. Don't cache"
was (Author: shinrich):
The problem is that I didn't define what the new attributes for
proxy.config.http.use_client_target_addr. The other problem is that my brain
doesn't work so well until after the 5th cup of coffee so I just noticed your
setting now.
proxy.config.http.use_client_target_addr = 0 - Means ignore the client used
address and rely on the proxy's DNS resolution of the host field (behavior
unchanged)
proxy.config.http.use_client_target_addr = 1 - Means use the client used
address, but do not cache if the client used address does not match one of the
proxy's DNS resolved addresses
proxy.config.http.use_client_target_addr = 2 - Means the same as 1 in previous
builds. Use the client used address. Cache in any case. Do not validate
against the proxy's DNS resolved addresses.
Originally I had proposed putting the new behavior on 2, but after talking with
Alan, we decided it would be safer to change the behavior of the already
deployed setting. Folks who really want to live dangerously can change the
setting to 2. By default deployments will gain the security improvement.
So your tests with proxy.config.http.use_client_target_addr = 2 are working as
designed. Sorry for not clarifying earlier. Could you give it a try with
proxy.config.http.use_client_target_addr = 1. I did your experiment and things
worked as I would expect.
The log message "(http_trans) [OSDNSLookup] DNS lookup for O.S. successful IP:
91.239.13.61" is a bit confusing. It is printing the IP address that has be
calculated for the OS regardless of whether a DNS lookup has been done or not.
> cache poisoning due to proxy.config.http.use_client_target_addr = 1
> -------------------------------------------------------------------
>
> Key: TS-2954
> URL: https://issues.apache.org/jira/browse/TS-2954
> Project: Traffic Server
> Issue Type: Bug
> Components: Cache, DNS, Security, TProxy
> Reporter: Nikolai Gorchilov
> Assignee: Susan Hinrichs
> Priority: Critical
> Fix For: 5.1.0
>
> Attachments: ts-2954.patch
>
>
> Current implementation of proxy.config.http.use_client_target_addr opens a
> very simple attack vector for cache poisoning in transparent forwarding mode.
> An attacker (or malware installed on innocent end-user computer) puts a fake
> IP for popular website like www.google.com or www.facebook.com in hosts file
> on PC behind the proxy. Once an infected PC requests the webpage in question,
> a cacheable fake response poisons the cache.
> In order to prevent such scenarios (as well as [some
> others|http://www.kb.cert.org/vuls/id/435052]) Squid have implemented a
> mechanism known as [Host Header Forgery
> Detection|http://wiki.squid-cache.org/KnowledgeBase/HostHeaderForgery].
> In short, while requesting an URL from origin server IP as hinted by the
> client, proxy makes independent DNS query in parallel in order to determine
> if client supplied IP belongs to requested domain name. In case of
> discrepancy between DNS and client IP, the transaction shall be flagged as
> non-cacheable to avoid possible cache poisoning, while still serving the
> origin response to the client.
--
This message was sent by Atlassian JIRA
(v6.2#6252)
