Description of a simple buffer overflow attack against older IMAP servers developed by the University of Washington.
801b38cc3b6e3bf19304acdeb6078697e05b7feabd89dcdfedd58d3099098ccd
Security advisory about buffer overflow attacks against UW-IMAP servers
-----------------------------------------------------------------------
This paper descripes a very old hack technique which is called buffer overflow
based on some security researches I made. It also shows a little what developers
have to look for to make their software secure against these type of attacks.
Affected are IMAP (Internet Message Access Protocol) servers from the University
of Washington older or equal to version 4. This bug is very old and all new versions
are not vulnerable against this. My examples are oriented on version 10.234.
Buffer overflows are all dealing with memory allocation in programs. All input
data a program/server takes are stored in variables with fixed sizes in the memory.
If input data size exceeds the memory limit it can overwrite machine code of the
application what permits attackers to exec arbitrary code. Examples are these IMAP
servers where the SASL (Secure Authentication and Secure Level) AUTHENTICATE procedure
was bad implemented. The problem appears in the mail_auth() procedure in mail.c of
the UW IMAP server source code distribution:
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 function is used to parse the SASL AUTHENTICATE command argument which should
specify an authentication mechanism to use (see RFC2222). The sore spot resides in
the strcpy() function which copies the data of mechanism to a char array of MAILTMPLEN
fields. MAILTMPLEN is defined as 1024 in mail.h so if the client passes an argument
>1024 bytes to the AUTHENTICATE command it would overwrite application data on the
stack and permits the attacker to execute arbitrary code on the remote machine which
will be the shell in most cases. When the server runs as root what is in case of most
IMAP servers the attacker will also gain root privileges.
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 should spawn the shell, must be impervious to mangling
by toupper(). For exploits you can look on www.securityfocus.com and www.securiteam.com.
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. If you are running such
a version it is safe to update it immediately.
OK that's all theoretical stuff you need first I think. For practice you can search the
Internet for actual buffer overflow exploits/advisories and study them. But don't break
into systems against the wishes of their owners!
Much fun!
by Lex@Lufix.net November '02
www.lufix.net