[
https://issues.apache.org/jira/browse/TS-2954?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=14079429#comment-14079429
]
Nikolai Gorchilov edited comment on TS-2954 at 7/30/14 4:21 PM:
----------------------------------------------------------------
Unfortunately, the following assert emerged just seconds after deployment in
production:
{noformat}
FATAL: HttpTransactHeaders.cc:675: failed assert `header->presence(mask) ==
mask`
/z/bin/traffic_server - STACK TRACE:
/z/lib/libtsutil.so.5(+0x1e837)[0x2b515c66d837]
/z/lib/libtsutil.so.5(+0x1d51f)[0x2b515c66c51f]
/z/bin/traffic_server[0x5d17f2]
/z/bin/traffic_server(HttpTransact::build_request(HttpTransact::State*,
HTTPHdr*, HTTPHdr*, HTTPVersion)+0xa0)[0x5b28d0]
/z/bin/traffic_server(HttpTransact::HandleCacheOpenReadHit(HttpTransact::State*)+0x1f9)[0x5c89c9]
/z/bin/traffic_server(HttpSM::call_transact_and_set_next_state(void
(*)(HttpTransact::State*))+0x66)[0x58e3a6]
/z/bin/traffic_server(HttpSM::state_api_callout(int, void*)+0x343)[0x599c43]
/z/bin/traffic_server(HttpSM::set_next_state()+0x1e8)[0x5a0518]
/z/bin/traffic_server(HttpSM::do_hostdb_lookup()+0x27a)[0x58e89a]
/z/bin/traffic_server(HttpSM::set_next_state()+0xcf8)[0x5a1028]
/z/bin/traffic_server(HttpSM::state_read_server_response_header(int,
void*)+0x1df)[0x59b66f]
/z/bin/traffic_server(HttpSM::main_handler(int, void*)+0xd8)[0x59add8]
/z/bin/traffic_server[0x715245]
/z/bin/traffic_server(NetHandler::mainNetEvent(int, Event*)+0x1ed)[0x707a1d]
/z/bin/traffic_server(EThread::process_event(Event*, int)+0x91)[0x736361]
/z/bin/traffic_server(EThread::execute()+0x4fc)[0x736e1c]
/z/bin/traffic_server[0x7355fa]
/lib64/libpthread.so.0(+0x7034)[0x2b515dc73034]
/lib64/libc.so.6(clone+0x6d)[0x2b515e9bdb5d]
{noformat}
Could it be related to refresh check of already cached result?
was (Author: ngorchilov):
Unfortunately, the following assert emerged just seconds after deployment in
production:
{noformat}
FATAL: HttpTransactHeaders.cc:675: failed assert `header->presence(mask) ==
mask`
/z/bin/traffic_server - STACK TRACE:
/z/lib/libtsutil.so.5(+0x1e837)[0x2b515c66d837]
/z/lib/libtsutil.so.5(+0x1d51f)[0x2b515c66c51f]
/z/bin/traffic_server[0x5d17f2]
/z/bin/traffic_server(HttpTransact::build_request(HttpTransact::State*,
HTTPHdr*, HTTPHdr*, HTTPVersion)+0xa0)[0x5b28d0]
/z/bin/traffic_server(HttpTransact::HandleCacheOpenReadHit(HttpTransact::State*)+0x1f9)[0x5c89c9]
/z/bin/traffic_server(HttpSM::call_transact_and_set_next_state(void
(*)(HttpTransact::State*))+0x66)[0x58e3a6]
/z/bin/traffic_server(HttpSM::state_api_callout(int, void*)+0x343)[0x599c43]
/z/bin/traffic_server(HttpSM::set_next_state()+0x1e8)[0x5a0518]
/z/bin/traffic_server(HttpSM::do_hostdb_lookup()+0x27a)[0x58e89a]
/z/bin/traffic_server(HttpSM::set_next_state()+0xcf8)[0x5a1028]
/z/bin/traffic_server(HttpSM::state_read_server_response_header(int,
void*)+0x1df)[0x59b66f]
/z/bin/traffic_server(HttpSM::main_handler(int, void*)+0xd8)[0x59add8]
/z/bin/traffic_server[0x715245]
/z/bin/traffic_server(NetHandler::mainNetEvent(int, Event*)+0x1ed)[0x707a1d]
/z/bin/traffic_server(EThread::process_event(Event*, int)+0x91)[0x736361]
/z/bin/traffic_server(EThread::execute()+0x4fc)[0x736e1c]
/z/bin/traffic_server[0x7355fa]
/lib64/libpthread.so.0(+0x7034)[0x2b515dc73034]
/lib64/libc.so.6(clone+0x6d)[0x2b515e9bdb5d]
{noformat}
> 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)
