[VulnWatch] IA WebMail Server 3.x Buffer Overflow Vulnerability

• Messages sorted by: [ date ] [ thread ] [ subject ] [ author ] [ attachment ]

To: bugs@securitytracker.com, vuln@secunia.com, vulnwatch@vulnwatch.org
Date: Mon, 03 Nov 2003 11:05:03 +0000

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 will 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

_________________________________________________________________
Find a cheaper internet access deal - choose one to suit you.
http://www.msn.co.uk/internetaccess

• Messages sorted by: [ date ] [ thread ] [ subject ] [ author ] [ attachment ]