[
https://issues.apache.org/jira/browse/TS-3743?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Sam Baskinger updated TS-3743:
------------------------------
Description:
One of the tests done on the [IronBee|http://www.ironbee.com] plugin for
TrafficServer is to send a [OWASP
Zap|https://www.owasp.org/index.php/OWASP_Zed_Attack_Proxy_Project] scan
through the proxy at a DokuWiki server. When this is done TrafficServer will
crash. The crash is not always at the same point in the scan, but is always
when IronBee is generating a custom block page. We've reviewed IronBee and
cannot find anything it is doing to provoke the crash.
The crash is always in {{HttpTunnel::producer_run (this=this@entry=0xaf6021c8,
p=p@entry=0xaf6022f8)}} and in all cases {{c->vc}} is invalid.
Our investigations correlated the crash with HttpSM's {{ua_session->m_active}}
being false. More specifically we suspect that
{{Http::SM::setup_internal_transfer()}} starts with {{ua_session->m_active}} as
true and then closes it -- setting {{ua_session->m_active}} to false -- before
{{tunnel.tunnel_run(p)}} is called at the end of the function.
Please refer to two attachments. The first is a copy of the stack trace we've
been working off of. Every crash has a remarkably similar call stack. The
second attachment is a patch that is working in our labs.
This crash also appears in the TrafficServer 4.x code, and the same patch seems
to resolve it.
was:
One of the tests done on the IronBee plugin for TrafficServer is to send a
OWASP Zap scan through the proxy at a DokuWiki server. When this was done a
repeatable but seemingly sporadic crash is observed when IronBee would request
that a block page be delivered to the client.
The crash was always in {{HttpTunnel::producer_run (this=this@entry=0xaf6021c8,
p=p@entry=0xaf6022f8)}} and in all cases {{c->vc}} was invalid.
Our investigations correlated the crash with HttpSM's {{ua_session->m_active}}
being false. More specifically we think that
{{Http::SM::setup_internal_transfer()}} starts with {{ua_session->m_active}} as
true and then closes it (setting {{ua_session->m_active}} to false) before
{{tunnel.tunnel_run(p)}} is called at the end of the function.
Please refer to two attachments. The first is a copy of the stack trace we've
been working off of. Every crash has a remarkably similar call stack. The
second attachment is a patch that is working in our labs.
This also appears in the TrafficServer 4.x series, and the same patch fixes our
problems.
> Crash Under Heavy Load and Sending Plugin Error Page
> ----------------------------------------------------
>
> Key: TS-3743
> URL: https://issues.apache.org/jira/browse/TS-3743
> Project: Traffic Server
> Issue Type: Bug
> Components: Core
> Reporter: Sam Baskinger
> Attachments: TS-3743.patch, stacktrace.txt
>
>
> One of the tests done on the [IronBee|http://www.ironbee.com] plugin for
> TrafficServer is to send a [OWASP
> Zap|https://www.owasp.org/index.php/OWASP_Zed_Attack_Proxy_Project] scan
> through the proxy at a DokuWiki server. When this is done TrafficServer will
> crash. The crash is not always at the same point in the scan, but is always
> when IronBee is generating a custom block page. We've reviewed IronBee and
> cannot find anything it is doing to provoke the crash.
> The crash is always in {{HttpTunnel::producer_run
> (this=this@entry=0xaf6021c8, p=p@entry=0xaf6022f8)}} and in all cases
> {{c->vc}} is invalid.
> Our investigations correlated the crash with HttpSM's
> {{ua_session->m_active}} being false. More specifically we suspect that
> {{Http::SM::setup_internal_transfer()}} starts with {{ua_session->m_active}}
> as true and then closes it -- setting {{ua_session->m_active}} to false --
> before {{tunnel.tunnel_run(p)}} is called at the end of the function.
> Please refer to two attachments. The first is a copy of the stack trace we've
> been working off of. Every crash has a remarkably similar call stack. The
> second attachment is a patch that is working in our labs.
> This crash also appears in the TrafficServer 4.x code, and the same patch
> seems to resolve it.
--
This message was sent by Atlassian JIRA
(v6.3.4#6332)
