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