[VulnWatch] metamail format string bugs and buffer overflows

From: Ulf Härnhamma (Ulf.Harnhammar.9485@private)
Date: Wed Feb 18 2004 - 11:40:32 PST

  • Next message: Peter Winter-Smith: "[VulnWatch] Web Crossing 4.x/5.x Denial of Service Vulnerability (FIX)"

    metamail format string bugs and buffer overflows
    
    
    PROGRAM: metamail
    VENDOR: Bell Communications Research, Inc. (Bellcore)
    DOWNLOAD URLs: ftp://thumper.bellcore.com/pub/nsb/
                   http://ftp.funet.fi/pub/unix/mail/metamail/
    VULNERABLE VERSIONS: 2.2, 2.4, 2.5, 2.6, 2.7, possibly others
    IMMUNE VERSIONS: 2.7 with my patch applied
    REFERENCES: CAN-2004-0104 (format string bugs)
                CAN-2004-0105 (buffer overflows)
    
    
    * DESCRIPTION *
    
    
    "Metamail is an implementation of MIME, the Multipurpose Internet
    Mail Extensions, a proposed standard for multimedia mail on the
    Internet. Metamail implements MIME, and also implements extensibility
    and configuration via the "mailcap" mechanism described in an
    informational RFC that is a companion to the MIME document."
    
    "In general, users will never run metamail directly. Instead,
    metamail will be invoked for the user automatically by the user's
    mail reading program, whenever a non-text message is to be viewed."
    
    (quoted from the program's documentation)
    
    metamail is one of the packages or ports in SUSE Linux, Debian
    GNU/Linux, Slackware Linux, Mandrake Linux, Gentoo Linux, Turbolinux,
    PLD Linux, FreeBSD, NetBSD, OpenBSD and old versions of Red Hat
    Linux, among others.
    
    There are several newsreaders (tin, slrn, nn), mailreaders (elm)
    and antivirus programs (antimime, older versions of AMaViS) that
    pass MIME messages from the network directly to metamail.
    
    
    * SUMMARY *
    
    
    I have found two format string bugs and two buffer overflows in
    metamail.
    
    
    * TECHNICAL DETAILS *
    
    
    The first format string bug occurs when a message has a
    "multipart/alternative" media type and one of the body parts has a
    "Content-Type" header with parameter names or values containing
    formatting codes. It occurs because of two bad fprintf() statements
    in the function SaveSquirrelFile() - yes, it's really called that -
    in metamail.c. The file "testmail1" gives an example of this problem.
    
    The second format string bug occurs when a message has encoded
    non-ASCII characters in the mail headers (as described in RFC 2047),
    an unknown encoding, and encoded text containing formatting codes. It
    is caused by a bad printf() statement in the function PrintHeader()
    in metamail.c. An example of this problem can be found in the file
    "testmail2".
    
    The first buffer overflow occurs when a message has encoded non-ASCII
    characters in the mail headers and the part that names a character
    set is overly long. The root of this problem is a bad strcpy()
    statement in the function PrintHeader() in metamail.c. An example
    of this can be found in the file "testmail3".
    
    The second buffer overflow doesn't occur in the metamail executable,
    but in the splitmail executable that's generated when you compile the
    metamail package. This overflow occurs when a message has an overly
    long Subject header. It is caused by a bad strcpy() statement in
    the function ShareThisHeader() in splitmail.c. An example can be
    found in the "testmail4.splitmail" file.
    
    
    * PATCH AND TEST MESSAGES *
    
    
    I have attached metamail.advisory-data.tar.gz, which contains the
    four test messages mentioned above, as well as a patch that corrects
    all four issues. The patch is diff'ed against version 2.7.
    
    In case your system administrator doesn't like .tar.gz attachments,
    I have also made this file available for downloading at
    http://labben.abm.uu.se/~ulha9485/metamail.advisory-data.tar.gz
    
    
    * TIMELINE *
    
    
    metamail is unmaintained, so I contacted the vendor-sec list instead.
    
    7 feb: the vendor-sec list (vendor-sec@private) was contacted
    9 feb: a coordinated release date was agreed upon
    Friday 13 feb (the day of the W2K source leak): CAN references
    were posted
    18 feb: Slackware released their advisory and updates
    18 feb: I release this advisory
    
    
    * 31337 IRC KIDDIES *
    
    
    K: "w0w d00d y4 ph0und b0th buphph3r 0v3rphl0wzZz 4nd ph0rm4t
    zZztr1ng bugzZz 1n m3t4m41l!!!! buphph3r 0v3rphl0wzZz (th3 0nly
    r34l s3cur1ty h0l3) 4r3 d4 k00l3zZzt but ph0rm4t zZztr1ng bugzZz
    (th3 0th3r r34l s3cur1ty h0l3) 4r3 r33ly k00l 4zZzw3ll!!!! d0 y4
    w4nn4 j01n 0ur h4ck3r gr0up 'h4ck3rzZz phr0m h3ll'??? w3 h4v3 4ll
    th3 l4t3zZzt w1nd0wzZz w4r3zZz 4nd w3 h4v3 4 pr3s3nc3 0n 1rc phr0m
    6 4m unt1l m1dn1ght c0z 0n3 0ph 0ur m3mb3rzZz' p4r3ntzZz l3t h1m
    st4y up l4t3!!!11!1!!!1!!!"
    
    U: "Virgin."
    
    
    // Ulf Harnhammar
       kses - PHP HTML/XHTML filter (no XSS)
       http://sourceforge.net/projects/kses
    
    
    
    



    This archive was generated by hypermail 2b30 : Wed Feb 18 2004 - 14:38:58 PST