Full Disclosure mailing list archives
Re: iDEFENSE Security Advisory 08.18.04: Courier-IMAP Remote Format String Vulnerability
From: Richard Johnson <thief () bugtraq org>
Date: Thu, 19 Aug 2004 01:19:45 -0400
A lot of people have been making fun of us for releasing bugs in rarely used configurations of software (Squid/NTLM), and now DEBUG message related vulnerabilities. On behalf of my cracker group, I would like to take a moment to publically explain how this is actually a serious issue and is nothing to be laughed at. Many people use Courier-IMAP. We aren't sure how many, but part of our team predicts that it is enough to merit a "HIGH" ranking (as will my upcoming XSS related vulnerabilities in Courier-IMAP). I don't see any of you critics releasing any better security advisories than we buy from drunk college students, so shut your mouths until you read the PaX[1] documentation at a Blackhat speech. The easiest way to exploit debugging-related vulnerabilities, such as this one, is to launch a disruption of service attack[2] of some sort to trick the admin into enabling the debug mode to figure out what is going wrong. While you are launching the disruption of service attack, loop attack probe until exploitation succeeds. So, as you can see, the threat here is HIGH! Further, a reasonably competent exploit coder might be able to bypass STACK PROTECTION MECHANISMS such as PaX, ExecShield, that kilt-wearing PhD guy's stuff. It could probably be exploited on obscure win32 STACK PROTECTION MECHANISMS also that attempt to emulate PaX. However, since there is no public testsuite to adequately deduce those results, and we aren't really sure what we're doing when we slightly modify code for public release, we'll have to have the ins1der do that sort of stuff for us. I guess this makes the threat BIG HIGH instead of simply just HIGH. We hope this clarification has done our genius the proper justice that we demand and deserve[3]. When I started GOBBLES, we made fun of people by releasing format string bugs in software and making a big deal out of it, because even idiots like ourselves could find them and claim they were exploitable. We even got away with our claims that we could bypass PaX/OpenWall/Cowan's Kilt. Now that I'm a respected member of the security community, I have to pretend to take myself seriously and let everyone know that I'm doing my part to fight terrorism by doing that same thing. I might not make a lot of sense, but my ego is perfect. [1] http://pax.grsecurity.net - a more complete copy of our presentation is online here. If you have any questions about it, please contact the PaX-Team. Hey I think this is called a footnote! [2] disruption of service attack - a term I pioneered in 1992 AD. [3] Using less than three footnotes is bad form. On Wed, Aug 18, 2004 at 12:32:55PM -0400, idlabs-advisories () idefense com wrote:
Courier-IMAP Remote Format String Vulnerability iDEFENSE Security Advisory 08.18.04 www.idefense.com/application/poi/display?id=131&type=vulnerabilities August 18, 2004 I. BACKGROUND Courier-IMAP is an IMAP/POP3 mail server popular on sites utilizing Qmail/Exim/Postfix. More information is available here: http://www.courier-mta.org/imap/ II. DESCRIPTION Remote exploitation of a format string vulnerability in Double Precision Inc.'s, Courier-IMAP daemon allows attackers to execute arbitrary code. The vulnerability specifically exists within the auth_debug() function defined in authlib/debug.c: void auth_debug( const char *fmt, va_list ap ) { char buf[DEBUG_MESSAGE_SIZE]; int i; int len; // print into buffer to be able to replace control and other // unwanted chars. vsnprintf( buf, DEBUG_MESSAGE_SIZE, fmt, ap ); len = strlen( buf ); // replace nonprintable chars by dot for( i=0 ; i<len ; i++ ) if( !isprint(buf[i]) ) buf[i] = '.'; // emit it fprintf( stderr, buf ); // <- Format String Vulnerability fprintf( stderr, "\n" ); } The 'buf' variable utilized in the fprintf() call is attacker-controlled and can contain format string modifiers allowing an attacker to manipulate the stack and eventually execute arbitrary code. III. ANALYSIS Successful exploitation does not require authentication thereby allowing any remote attacker to execute arbitrary code under the privileges of the user that the IMAP daemon runs as. The vulnerable function auth_debug() is only called if login debugging is enabled requiring that the 'DEBUG_LOGIN' be set to either '1' or '2' in the imapd configuration file. IV. DETECTION iDEFENSE has confirmed the existence of this vulnerability in Courier-IMAP, v2.2.1. It is reported that all versions of Courier-IMAP from 1.6.0 to 2.2.1 inclusive are vulnerable. V. WORKAROUND Disable the login debugging option of Courier-IMAP. This can be accomplished by setting 'DEBUG_LOGIN' to '0' in the configuration file usually located at /usr/lib/courier-imap/etc/imapd. VI. VENDOR RESPONSE This issue has been resolved in the latest version of Courier IMAP (v3.0.7). As well, the default setting of 'DEBUG_LOGIN' is '0'. VII. CVE INFORMATION The Common Vulnerabilities and Exposures (CVE) project has assigned the name CAN-2004-0777 to this issue. This is a candidate for inclusion in the CVE list (http://cve.mitre.org), which standardizes names for security problems. VIII. DISCLOSURE TIMELINE 08/10/2004 Initial vendor contact 08/10/2004 iDEFENSE clients notified 08/11/2004 Initial vendor response 08/18/2004 Public disclosure IX. CREDIT An anonymous contributor is credited with discovering this vulnerability. Get paid for vulnerability research http://www.idefense.com/poi/teams/vcp.jsp X. LEGAL NOTICES Copyright (c) 2004 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 customerservice () idefense com 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, this information. _______________________________________________ Full-Disclosure - We believe in it. Charter: http://lists.netsys.com/full-disclosure-charter.html
-- Richard "I am the PaX Team" Johnson, CISSP Senior Security Researcher Undisputed Founder of GOBBLES Security iDEFENSE Inc. thief () bugtraq org Get paid for security stuff!!!!!! http://www.idefense.com/contributor.html and become part of our research team! http://idefense.bugtraq.org/ _______________________________________________ Full-Disclosure - We believe in it. Charter: http://lists.netsys.com/full-disclosure-charter.html
Current thread:
- iDEFENSE Security Advisory 08.18.04: Courier-IMAP Remote Format String Vulnerability idlabs-advisories (Aug 18)
- Re: iDEFENSE Security Advisory 08.18.04: Courier-IMAP Remote Format String Vulnerability Kyle Maxwell (Aug 18)
- Re: iDEFENSE Security Advisory 08.18.04: Courier-IMAP Remote Format String Vulnerability Richard Johnson (Aug 18)