VENDOR: Bell Communications Research, Inc. (Bellcore)
DOWNLOAD URLs: ftp://thumper.bellcore.com/pub/nsb/
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
* TIMELINE *
metamail is unmaintained, so I contacted the vendor-sec list instead.
7 feb: the vendor-sec list (email@example.com) 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!!!"
// Ulf Harnhammar
kses - PHP HTML/XHTML filter (no XSS)