[
https://issues.apache.org/jira/browse/TS-2954?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=14071921#comment-14071921
]
Susan Hinrichs commented on TS-2954:
------------------------------------
Yes, the use_client_target_addr does expose a cache poisoning attack. The Host
Header Forgery Detection would solve it in some (most?) cases.
If the client and the trafficserver have access to the same DNS information
then the Host Header Forgery Detection would solve the problem. The client
could specify which specific server address the name should resolve to
(important if the IP address is embedded elsewhere in the protocol). And
trafficserver could verify this. The cache poisoner would be caught out.
However, if you have a scenario where the client has access to different DNS
information than the trafficserver, the Host Header Forgery Detection would not
help. Perhaps the client is sitting with access to a corporate DNS server that
the trafficserver does not have access to.
Perhaps a tiered solution would work? By default set up
proxy.config.http.use_client_target_addr to also employ Host Header Forgery
Detection. Then add another option to disable the Host Header Forgery
Detection in the small set of cases that have DNS mismatches between the client
and the proxy.
> 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
> Priority: Critical
>
> 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)
