[ 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)