Hi,
Now I nearly have 100% confidence that CVE-2017-5659 is introduced by TS-3612.
And only impact 6.2.0 and later.
I made two private image:
the 1st one is based on commit “af76977adb9f3c0296a232688bbcb5a1421a6768”,
which is for TS-3612;
the 2nd one is based on commit “af76977adb9f3c0296a232688bbcb5a1421a6768”,
which is one commit before TS-3612 introduced.
With the same configuration and test steps, only the 1st one reproduced this
ATS crash issue. So I think now we can conclude that CVE-2017-5659 only impact
6.2.0 and later.
Please correct me if I missed something.
Thanks,
Zhilin
On 5/2/17, 6:31 PM, "Zhilin Huang (zhilhuan)" <zhilh...@cisco.com> wrote:
Hi Bryan,
I made a positive progress today.
As TS-3612 which restructured ATS Proxy Client Session code is introduced
until 6.2, I suspect that this issue only exists on 6.2.0 and later.
Then I finally made ATS 6.2.0 crash using a modified version of
test_post.py. And with the same script, ATS 5.3.2 did not crash. My
modification is not using “request_session.proxies” in the python code (which
means use reverse proxy instead of forward proxy), and make sure the request
URL working by HTTP GET, even the crash is caused by HTTP POST.
With above evidence, do you think I can safely conclude that ATS 5.3.2 is
not affected by CVE-2017-5659? Thanks in advance for any advices.
Thanks,
Zhilin
On 4/28/17, 10:15 PM, "Zhilin Huang (zhilhuan)" <zhilh...@cisco.com> wrote:
Hi Bryan,
Thanks for the response.
I also got ERR_CLIENT_ABORT in the translog. Not sure if the crash
needs some special configuration.
Thanks,
Zhilin
On 4/28/17, 12:05 AM, "Bryan Call" <bc...@apache.org> wrote:
I couldn’t get it to crash on ATS 5.3.x myself. I am seeing this
in the squid logs after the request:
1493308994.894 56 216.161.80.88 ERR_CLIENT_ABORT 000 0 POST …
-Bryan
> On Apr 27, 2017, at 8:18 AM, Zhilin Huang (zhilhuan)
<zhilh...@cisco.com> wrote:
>
> Hi,
>
> I know ATS 5.3.2 may be end of support. But it would be very
appreciated if someone can suggest if 5.3.2 is affected by CVE-2017-5659.
>
> Currently we are still using 5.3.2 in production, and want to
evaluate how to back port CVE-2017-5659 to 5.3.2 by ourselves.
>
> However, looks like the code base is quite different. If my
understanding is right, the fix is actually introduced in TS-4507 by PR #787.
And it seems like a regression from TS-3612, but I am not quite sure about
this. If it is truly a regression from TS-3612, does this mean 5.3.2 is not
affected?
>
> BTW, we could not reproduce this issue by the test tool attached
in https://issues.apache.org/jira/secure/attachment/12827263/test_post.py .
Would someone kindly help to provide some suggestion on how to reproduce this
issue using this tool? Is there any configuration precondition?
>
> Thanks in advance!
>
>
> Thanks,
> Zhilin
>
>
