There is a format string vulnerability in the auth_debug() function which can be exploited remotely.
This vulnerability can only be exploited if DEBUG_LOGIN is set to something other than 0 in the imapd config file.
Courier versions 1.6.0 through 2.2.1 (inclusive) are affected.
I should emphasize that this is potentially a remote root, as courier-imapd usually runs with root privileges so that it can access users' mailboxes.
robbat2, or someone from net-mail -- can you please look at the iDEFENSE advisory and tell us what you think? Will an upgrade to 3.0.x fix the problem? I know that we still have a 2.1.2 version in Portage; would it be possible to remove that?
I don't think we need to do any keywording; 3.0.2 is already marked stable everywhere it counts.
Security -- I am assuming that since this is a remote root, it's worthy of GLSAage, even though (a) it's for an old version, and (b) it requires debugging to be turned on. What are your thoughts?
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'.
Guess we have to bump. robbat2 is on vacation, I'll get the 3.0.7 in the tree very soon.
> Courier versions 1.6.0 through 2.2.1 (inclusive) are affected.
I've missed. I've checked authlib/debug.c from 3.0.2 to 3.0.5 and confirm that the Format String Vulnerability code have been removed.
courier-imap-3.0.2.ebuild is stabled for all the arches that have stable keyword with courier-imap-2.1.2-r2.ebuild. ITW, I've removed courier-imap-2.1.2-r2.ebuild from the tree and no other action need on net-mail part or the arches team.
Arches: please test net-mail/courier-imap-3.0.5 and mark stable.
I've gone over the different versions (I looked at 2.1.2, 3.0.2, 3.0.4 and 3.0.5).
As far as I can tell, everything up through 3.0.2 (inclusive) is vulnerable. The problem is the "fprintf( stderr, buf );" line. In both 2.1.2 and 3.0.2, this is at authlib/debug.c:83.
3.0.4 is not vulnerable, but 3.0.5 is already in the tree, so we might as well bump to that. I will write the GLSA to reflect this unless someone tells me I'm being stupid. ;)
stable on ppc
x86 done. remove them.
Updating status whiteboard.
Thanks to everyone for responding so quickly.
Done on hppa.
sorry to reopen this, but could the following arches please see bug #61464.
x86 ppc sparc hppa amd64
I'd like to get 3.0.7 as stable, since 3.0.5 has a number of issues that got fixed in 3.0.6.
This is what I get for bumps for security updates while I'm on vacation.
Robin/security team -- Is it worth it to issue errata for that GLSA?
For those who use OUTBOX and it doesn't work, it seems like they would just naturally try to upgrade, and if 3.0.7 is stable, everything will be fine.
Arches please mark 3.07 stable.
This is not strictly a security bug so I don't think a GLSA is needed.
I'd say we don't need any errata, but we do need to get the new version in stable.
stable on amd64
Stable on sparc.
all arches are done
All done. Closing without a new GLSA