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