[VulnWatch] iDEFENSE Security Advisory 09.09.05: GNU Mailutils 0.6 imap4d 'search' Format String Vulnerability
From: iDEFENSE Labs (labs-no-reply_at_idefense.com)
Date: Fri, 9 Sep 2005 12:45:20 -0400 To: <email@example.com>, <firstname.lastname@example.org>, <email@example.com>
GNU Mailutils 0.6 imap4d 'search' Format String Vulnerability
iDEFENSE Security Advisory 09.09.05
September 09, 2005
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:
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 authenticated attacker to execute arbitrary code.
The imap4d server allows remote users to retrieve e-mail via the
Internet Message Access Protocol, Version 4rev1 as specified in
RFC3501. This is a client/server protocol supported by a large number
of e-mail clients on multiple platforms.
The vulnerability specifically exists in the handling of SEARCH commands
supplied by the remote user. If a search is made containing format
specifiers (such as %p or %s), these will be interpreted by the server,
and returned to the user. The vulnerable code, search.c, lines 198-199,
are shown below:
rc = imap4d_search0 (arg, 0, buffer, sizeof buffer);
return util_finish (command, rc, buffer);
The vulnerability specifically occurs because the util_finish() function
expects a format specifier in the 3rd argument, followed by any
arguments to be formatted. Without a specifier, the function interprets
the 3rd argument as a format specifier.
Exploitation could allow authenticated remote attackers to execute
arbitrary commands on an affected system as the authenticated user. This
may allow access to systems not intended to have interactive users,
which could allow further compromise. Using format specifiers, it is
possible to construct a sequence of commands that cause arbitrary values
to be written to arbitrary locations, allowing arbitrary code execution.
An example session demonstrating the vulnerability follows:
sh-2.05b$ netcat 192.168.0.1 143
* OK IMAP4rev1
1 LOGIN "user" "password"
1 OK LOGIN Completed
2 SELECT "inbox"
* 23 EXISTS
* 0 RECENT
* OK [UIDVALIDITY 1118516013] UID valididy status
* OK [UIDNEXT 24] Predicted next uid
* OK [UNSEEN 1] first unseen messsage
* FLAGS (\Answered \Flagged \Deleted \Seen \Draft)
* OK [PERMANENTFLAGS (\Answered \Deleted \Seen)] Permanent flags
2 OK [READ-WRITE] SELECT Completed
3 SEARCH TOPIC %08x.%08x.%08x.%08x
3 BAD SEARCH Unknown search criterion (near
4 SEARCH TOPIC %s%s%s
The result of the 'SEARCH TOPIC %08x.%08x.%08x.%08x' command contains
values from the error string supplied to the output function. (6e6b6e55
converts to 'Unkn', 206e776f converts to 'own ' and 72616573 converts to
'sear'.) By referencing the values after the fixed string in the error
message, which are under control of the attacker, and using the '%n'
format specifier, controllable values can be written to arbitrary memory
locations, allowing execution of arbitrary code.
The '%s%s%s' format specifier attempts to treat the first 3 values
(0x00000040, 0x6e6b6e55 and 0x206e776f) as strings, and causes an access
violation error, terminating the server connection, dropping the user
back into their shell. The main server is still active, as the server
forks a new copy for each connection. This allows multiple exploitation
iDEFENSE Labs has verified the existence of this vulnerability in
versions 0.6 of the GNU Mailutils package. It is suspected that any
previous versions that contain the imap4d server are also affected.
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
VI. VENDOR RESPONSE
A vendor advisory for this issue is available at:
A patch is available at:
VII. CVE INFORMATION
A Mitre Corp. Common Vulnerabilities and Exposures (CVE) number has not
been assigned yet.
VIII. DISCLOSURE TIMELINE
09/08/2005 Initial vendor notification
09/09/2005 Initial vendor response
09/09/2005 Coordinated public disclosure
The discoverer of this vulnerability wishes to remain anonymous.
Get paid for vulnerability research
Free tools, research and upcoming events
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 firstname.lastname@example.org 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,