exploit the possibilities
Home Files News &[SERVICES_TAB]About Contact Add New

imapd_overflow

imapd_overflow
Posted Jul 28, 2003
Authored by sac, LexLufix | Site sac.cc

Description of a simple buffer overflow attack against older IMAP servers developed by the University of Washington.

tags | advisory, overflow, imap
SHA-256 | 801b38cc3b6e3bf19304acdeb6078697e05b7feabd89dcdfedd58d3099098ccd

imapd_overflow

Change Mirror Download
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

Login or Register to add favorites

File Archive:

November 2024

  • Su
  • Mo
  • Tu
  • We
  • Th
  • Fr
  • Sa
  • 1
    Nov 1st
    30 Files
  • 2
    Nov 2nd
    0 Files
  • 3
    Nov 3rd
    0 Files
  • 4
    Nov 4th
    12 Files
  • 5
    Nov 5th
    44 Files
  • 6
    Nov 6th
    18 Files
  • 7
    Nov 7th
    9 Files
  • 8
    Nov 8th
    8 Files
  • 9
    Nov 9th
    3 Files
  • 10
    Nov 10th
    0 Files
  • 11
    Nov 11th
    0 Files
  • 12
    Nov 12th
    0 Files
  • 13
    Nov 13th
    0 Files
  • 14
    Nov 14th
    0 Files
  • 15
    Nov 15th
    0 Files
  • 16
    Nov 16th
    0 Files
  • 17
    Nov 17th
    0 Files
  • 18
    Nov 18th
    0 Files
  • 19
    Nov 19th
    0 Files
  • 20
    Nov 20th
    0 Files
  • 21
    Nov 21st
    0 Files
  • 22
    Nov 22nd
    0 Files
  • 23
    Nov 23rd
    0 Files
  • 24
    Nov 24th
    0 Files
  • 25
    Nov 25th
    0 Files
  • 26
    Nov 26th
    0 Files
  • 27
    Nov 27th
    0 Files
  • 28
    Nov 28th
    0 Files
  • 29
    Nov 29th
    0 Files
  • 30
    Nov 30th
    0 Files

Top Authors In Last 30 Days

File Tags

Systems

packet storm

© 2024 Packet Storm. All rights reserved.

Services
Security Services
Hosting By
Rokasec
close