Bugzilla – Bug 58991
VUL-0: CVE-2004-0777: courier-imap: format string vulnerability
Last modified: 2021-10-12 13:32:15 UTC
The following advisory was posted on full disclosure: Date: Wed, 18 Aug 2004 12:32:55 -0400 From: idlabs-advisories@idefense.com To: idlabs-advisories@idefense.com Subject: [Full-Disclosure] iDEFENSE Security Advisory 08.18.04: Courier-IMAP Remote Format String Vulnerability Reply-To: customerservice@idefense.com X-Spam-Level: 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
So the default is that debugging is disabled. This is the case for our versions. Do we really need to do something here for a leaf package?
Well, according to a guy that answered the advisory it is not quite as harmless as is sounds. An attacker trying to exploit this would try to disturb the service first to have the admin turn on debugging to see what's going on.
please check the versions mentioned in the advisory and in the release branches. Newer versions of courier-imap are not affected. We introduced it with 9.0 and only 9.0 is affected, since 9.1 has a newer one where the code looks more correct.
Created attachment 22810 [details] patch to fix problem patch to fix. compiles, but untested.
About comment #3: The advisory is not correct: They claim 2.x as defect and fixed with 3.0.7. But 3.0-3.0.6 are also defect (but they say nothing about this). Our 9.1 version has the same code as 9.0 in debug.c. The problem is: Did anybody of you ever run an online update on 9.0 with an old computer and modem? I hope you will not need your phone during the next days after starting it. We have to compare the risk of the defect with usability and the risk to update. And in this case, there is only a very low risk (if the admin forgets to disable debug mode after he used it), compared with a higher risk that something during the update goes wrong, a bad usability and the bad press that there are more updates than GB on CDs (people are complaining about this already, computer magazines are complaining about this and we try to create PatchCDs for them so that they are more happy). Applying this small patch to both versions is no problem, but it seems nobody thinks about the work and consequences which follows of this. About comment #2: This answer is stupid. If the admin switch on debugging to see what's going on, he will see the attackers try to compromise the service. And he will watch the log file because he enabled it do to so to fix the service.
#3, yes, you are right. the same patch would apply. Regarding the need of an update ... I agree with your points. I think this issue is not important enough to warrant an update, but we must make sure it is fixed in STABLE.
It was fixed in STABLE 4 days ago ;-)
CVE-2004-0777: CVSS v2 Base Score: 7.5 (AV:N/AC:L/Au:N/C:P/I:P/A:P)