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 >> >> > > > > > > >
