GNU Mailutils 0.6 imap4d Format String Vulnerability

iDEFENSE Security Advisory 05.25.05
http://www.idefense.com/application/poi/display?type=vulnerabilities
May 25, 2005

I. BACKGROUND

The GNU mailutils package is a collection of mail-related
utilities, including local and remote mailbox access services.
More information is available at the following site:

    http://www.gnu.org/software/mailutils/mailutils.html

II. DESCRIPTION

Remote exploitation of a format string vulnerability in the
imap4d server within version 0.6 of the GNU Project's Mailutils
package could allow an unauthenticated attacker to execute
arbitrary code.

The imap4d server allows remote users to retrieve their email
via the Internet Message Access Protocol, Version 4rev1 as
specified in RFC3501. This is a client/server protocol supported
by a large number of email clients on multiple platforms.

The vulnerability specifically exists in the handling of the
command tag supplied by the remote user. Each client command
sent to the server is prefixed with an identifier which is
typically a short alphanumeric string such as "A0001". A
different tag is generated by the client for each command.  When
the server has completed the task, with either success or
failure, the server will send a reply with the same tag.

The following snippet of code shows some of the vulnerable code:

  asprintf (&tempbuf, "%s %s%s %s\r\n", command->tag, sc2string (rc),
            command->name, format);
  va_start (ap, format);
  vasprintf (&buf, tempbuf, ap);

The asprintf() command allocates a new string, created by
joining the values of the tag supplied by the remote user, the
text version of the result code, the name of the command being
executed, and the original format string supplied to this
function.

The effect of this line is to generate a new format string
string which is used to generate the output. As there is no
check for format specifiers in the user supplied input, a
remotely exploitable condition occurs.

III. ANALYSIS

Successful exploitation allows remote unauthenticated attackers
to execute arbitrary commands on an affected system as the
'daemon' user.

Sending the following command to an affected server will cause
the current connection to die when the fork()ed instance of the
server crashes:

%n%n%n%n%n die.

The '%n' format specifier writes the number of characters in the
output string generated so far to the memory address pointed at
by the current argument. In this case, the process attempts to
write the value 0 to the next 5 memory locations in the argument
list. As some of these arguments are not valid pointers, the
server dies attempting to write to an invalid memory location. 
This will not cause a denial of service, as a new instance of
the server is spawned for each accepted connection.

Information about the values on the stack below the current
position can be gained by sending a string similar to:

%p-%p-%p-%p-%p-%p-%p-%p-%p-%p-%p info

Using these format specifiers it is posslbe to contrstruct a
sequence of commands which will cause arbitrary values to be
written to arbitrary locations, allowing the execution of
arbitrary code.

IV. DETECTION

iDEFENSE Labs has verified the existance of this vulnerability
in versions 0.5 and 0.6 of the GNU Mailutils package. It is
suspected that any previous versions which contain the imap4d
server are also affected.

V. WORKAROUND

iDEFENSE is currently unaware of any effective workarounds for
this issue.  Access to the affected host should be filtered at
the network boundary if global accessibility is not required.
Restricting access to only trusted hosts and networks may reduce
the likelihood of exploitation.

VI. VENDOR RESPONSE

This vulnerability has been fixed in GNU mailutils 0.6.90 which is
available for download at:

   ftp://alpha.gnu.org/gnu/mailutils/

VII. CVE INFORMATION

The Common Vulnerabilities and Exposures (CVE) project has assigned the
name CAN-2005-1523 to this issue. This is a candidate for inclusion in
the CVE list (http://cve.mitre.org), which standardizes names for
security problems.

VIII. DISCLOSURE TIMELINE

05/12/2005  Initial vendor notification
05/12/2005  Initial vendor response
05/25/2005  Public disclosure

IX. CREDIT

infamous41md@hotpop.com is credited with the discovery of this
vulnerability.

Get paid for vulnerability research
http://www.idefense.com/poi/teams/vcp.jsp

Free tools, research and upcoming events
http://labs.idefense.com

X. LEGAL NOTICES

Copyright (c) 2005 iDEFENSE, Inc.

Permission is granted for the redistribution of this alert
electronically. It may not be edited in any way without the express
written consent of iDEFENSE. If you wish to reprint the whole or any
part of this alert in any other medium other than electronically, please
email customerservice@idefense.com for permission.

Disclaimer: The information in the advisory is believed to be accurate
at the time of publishing based on currently available information. Use
of the information constitutes acceptance for use in an AS IS condition.
There are no warranties with regard to this information. Neither the
author nor the publisher accepts any liability for any direct, indirect,
or consequential loss or damage arising from use of, or reliance on,
this information.
_______________________________________________
Full-Disclosure - We believe in it.
Charter: http://lists.grok.org.uk/full-disclosure-charter.html
Hosted and sponsored by Secunia - http://secunia.com/