IA WebMail Server 3.x Buffer Overflow Vulnerability ################################################### Credit: Author : Peter Winter-Smith Software: Package : IA WebMail Server Versions : All up to and including 3.1 Vendor : True North Software Vendor Url : http://www.tnsoft.com Vulnerability: Bug Type : Stack-based Buffer Overflow Severity : Highly Critical + Denial of Service + Code Execution as SYSTEM 1. Description of Software "IAŽ WebMail Server combined with the IAŽ eMailServer is a powerful combination for remote access. The IAŽ WebMail Server will work with any standard Web browser to allow users access to their email from anywhere on the Internet. Most mail client programs require that they be reconfigured each time they are used by a different user. This feature is a definite boon to any user who travels or works from outside the office on occasion." - Vendors Description 2. Bug Information The WebMail Server contains a buffer overflow in the HTTP GET request headers. If a page of 1044 bytes is requested, a saved return address on the stack is completely overwritten, and the instruction pointer can be fully controlled upon the execution of a 'retn' instruction. It is also possible to gain control of the ECX register during the process. IA WebMail Server has an option to be run as a service with SYSTEM privileges, although this is NOT selected by default, I would assume that many servers would select this as a failsafe in case they needed to reboot or suffered a crash of a sort. (a). Denial of Service Upon sending an overly long string to the WebMail Server application, if the saved return address or ECX register is overwritten, the server will not crash and display an error message, instead it will go on indefinitely, consuming 100% system resources until the system crashes. Any further requests to the application will not be answered. (b). Buffer Overflow Upon sending a specially crafted, malicious string of code to the server, I have found it possible to execute an extensive amount of code on the remote system. It is possible to execute a fairly small amount of code after the instruction pointer using the 'jmp esp' method; a good and fairly static 'jmp esp' instruction can be located in the iaregdll.dll file accompanying the server. It is also possible to execute a fairly large amount of code (over 1kb) by jumping back into the buffer; the addresses at which the buffer appears seem very static for each operating system, I have not had a single failing with executing my proof of concept code in either case as of yet. There are a few bytes which must be avoided by xor'ing, or some such routine during the exploitation of the overflow, but even with this added problem, I did not find it difficult to execute my specially crafted code. (i). Part of the Vulnerable Code This section is added for researchers, to give them a head start in locating the vulnerable function. The overflow is caused by an unchecked call to lstrcpya(). A call is made from 0x0041B98C to 0x0041D850, and the saved return address 0x0041B991 is placed on the stack. :0041B98A 8BCE mov ecx, esi :0041B98C E8BF1E0000 call 0041D850 In the sub procedure (0x0041D850), at 0x0041D8BB a pointer to a jmp strcpy() type instruction is located. :0041D8BB 8B2DCCA04200 mov ebp, dword ptr [0042A0CC] ; <- lstrcpya() :0041D8C1 40 inc eax :0041D8C2 8D4C2430 lea ecx, dword ptr [esp+30] :0041D8C6 50 push eax ; <- User supplied data :0041D8C7 51 push ecx ; <- Unchecked buffer :0041D8C8 FFD5 call ebp ; <- Call strcpy() At this point the saved return address has been overwritten, and we are just waiting for the following return instruction. * Reference To: MFC42.Ordinal:0320, Ord:0320h | :0041DC45 E8F2830000 Call 0042603C :0041DC4A 8B8C2434040000 mov ecx, dword ptr [esp+00000434] :0041DC51 5F pop edi :0041DC52 5E pop esi :0041DC53 5D pop ebp :0041DC54 33C0 xor eax, eax :0041DC56 64890D00000000 mov dword ptr fs:[00000000], ecx :0041DC5D 5B pop ebx :0041DC5E 81C430040000 add esp, 00000430 :0041DC64 C3 ret ; <- Here we gain control of the EIP The altered saved return address is pop'ed off the stack instead of the real saved return address. 3. Proof of Concept Although I have proven that code execution is possible, and have managed to construct several working exploits, I have decided against releasing any exploits to the public at this point. I am still unsure of when I will release any code, although it will most probably be when a patch has been released by True North Software. If there is a genuine need for a proof of concept exploit, then I will provide one, but I'll have to believe your argument for it ;o) I don't doubt that most of you reading this could construct your own anyway :-p If I release one, it can be found on my website at: o http://www.elitehaven.net/exploits.htm 4. Patches - Workarounds As of writing, there are no patches released, however I have contacted the vendor and I would expect that one will be released soon. The only existing workaround would be to use some kind of filtering software to filter out overly long requests. I had written an patch in assembler which would move the saved return address into the ESI register, execute the strcpy() call, and replace the return address, except I had more than my fair share of problems implementing it. 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., Martine(!) and all those who have helped and supported my research! Thanks to all the researchers, consultants and computer professionals who dedicate countless hours to their work; some day when I leave school I hope to do work as great as you guys o This document should be mirrored at http://www.elitehaven.net/iawebmail.txt