Hi Bryan,
Thank you for the confirmation. We feel safer now. ☺
Thanks,
Zhilin
On 5/4/17, 12:27 AM, "Bryan Call" <bc...@apache.org> wrote:
I was able to confirm that the commit that caused this problem is
af76977adb9f3c0296a232688bbcb5a1421a6768.
Thank you for tracking it down to this commit.
-Bryan
> On May 2, 2017, at 8:07 PM, Zhilin Huang (zhilhuan) <zhilh...@cisco.com>
wrote:
>
> 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
>>
>>
>
>
>
>
>
>
>
