Sorry about the typo, the 2nd one is based on commit 
“e3aaf85b42d1cec3676f4db5a9560372380ec6c9”.

Thanks,
Zhilin



On 5/3/17, 11:07 AM, "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
                > 
                > 
                
                
            
            
        
        
    
    

Reply via email to