Hi Bryan,
Thank you for the confirmation. We feel safer now. ☺
Thanks,
Zhilin
On 5/4/17, 12:27 AM, "Bryan Call" wrote:
I was able to confirm that the commit that caused this problem is
af76977adb9f3c0296a232688bbcb5a1421a6768.
Thank you for tracking it down to this commit.
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)
> wrote:
>
> Hi,
>
> Now I nearly have 100% confidence that CVE-2017-5659 i
Sorry about the typo, the 2nd one is based on commit
“e3aaf85b42d1cec3676f4db5a9560372380ec6c9”.
Thanks,
Zhilin
On 5/3/17, 11:07 AM, "Zhilin Huang (zhilhuan)" wrote:
Hi,
Now I nearly have 100% confidence that CVE-2017-5659 is introduced by
TS-3612. And only impact 6.2.0 and lat
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 “af76977adb9f3c0296a232
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
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" wrote:
I couldn’t get it to crash on ATS 5.3.x myself. I am seeing this in the
squid logs after the
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)
> wrote:
>
> Hi,
>
> I know ATS 5.3.2 may be end of support. But
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 b
