Re: iDEFENSE Security Advisory 08.18.04: Courier-IMAP Remote Format String Vulnerability

[Richard Johnson <thief () bugtraq org>]

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