Multiple buffer overflow vulnerabilities have been identified in Courier MTA, Courier SqWebMail, and Courier-IMAP. These vulnerabilities may allow a remote attacker to execute arbitrary code on a vulnerable system in order to gain unauthorized access. Reproducible: Didn't try Steps to Reproduce: 1. 2. 3. Have a look at http://www.securityfocus.com/bid/9845/discussion/: Multiple buffer overflow vulnerabilities have been identified in Courier MTA, Courier SqWebMail, and Courier-IMAP. These vulnerabilities may allow a remote attacker to execute arbitrary code on a vulnerable system in order to gain unauthorized access. The issues exist in the 'SHIFT_JIS' converter in 'shiftjis.c' and 'ISO2022JP' converter in 'so2022jp.c'. An attacker may be able to exploit these issues by supplying Unicode characters that exceed BMP (Basic Multilingual Plane) range. These issues have been reported to affect Courier MTA 0.44.2 and prior, Courier-IMAP 2.2.1 and prior, and Courier SqWebMail 3.6.2 and prior. It has also been reported that the vulnerable codeset mappings may be employed by the Courier IMAP and Webmail service, however, they are not enabled by default. These issues are being further analyzed and this BID will be updated once analysis is complete. Solution would be to upgrade to courier-IMAP 3.0.0.
Courier 3.0.2 is out, so might as well just bump to that version. I have an ebuild for this, which I am testing now. I'll attach it here when I'm sure it works.
Created attachment 27944 [details] courier-imap-3.0.2.ebuild Here is the 3.0.2 ebuild. I had to tweak two of the patches, and remove the third. The two new patches are coming shortly. NOTE that I have only tested the SSL imapd, and not normal IMAP or POP3/POP3-SSL. But the imapd-ssl seems to work fine.
Created attachment 27945 [details, diff] courier-imap-3.0.2-db40vs41.patch First patch. OY. I also forgot to mention, the ebuild I attached probably should be marked ~x86. It's marked stable right now because I tested it on my "stable" server (ha), and forgot to change it before I submitted it.
Created attachment 27946 [details, diff] courier-imap-3.0.2-removerpm.patch Second patch.
i've tested this on a non-production server, imap/pop3 seems to work fine, did not test -ssl variants.
imap-ssl works for me on my personal mail server.
Thanks for the ebuild. pop/pop3-ssl, imap/imap-ssl work as advertise on my home server.
hrmm anybody from net-mail@ going to act on this one? bug opened >=48hrs I'll bump this in portage to ~arch if you guys (bug reporters) help confirm it works.
3.0.2 in portage as ~arch. It compiles clean over here, but it's still up to the mail herd and arch-maintainers to test & confirm if it's stable or not. Adding them to CC by herd name for testing.
[ebuild R ] net-mail/courier-imap-3.0.2 +berkdb -fam +gdbm +ldap +mysql +nls +pam -postgres 0 kB Can somebody that uses fam & postgres please test with those USE flags.
works fine with +fam
confirmed working with +fam +postgres
sorry about the lack of response on this from me. i've cleaned up the ebuild a bit, and hammered on it for some testing, and it seems to be stable so I've marked it as x86.
I just completed an update using the ebuild from http://bugs.gentoo.org/show_bug.cgi?id=45584 and then did an emerge clean - 1) /usr/lib/courier-imap/gentoo-courier-imap-*.rc were not included in the new ebuild. 2) /usr/sbin/mkimapdcert and mkpop3dcert were not installed either. Not sure why these problems arose, but luckily I was able to copy them from an other mail server and get back online. I don't have time to debug the ebuild, but make backups of these files before an update.
regarding #14: did you place the ebuild inside the current courier-imap dir ? It needs a lot of files from the existing files/ directory as an addendum to #5, we just moved it into production (no ssl/fam/*sql), still works fine :)
re#15 No I did not I put it in /usr/local/portage/net-mail/courier-imap/ - I will remember next time to copy the old directory there insead of creating a new one. I just did not want it overwritten by the next rsync. I am sure that now that it is in portage things should be fine.
Stable on AMD64, removing from CC
Stable on sparc.
Stable on hppa. Removing CC
sejo bumped it on ppc as well, removing ppc from the list
This is ready for a GLSA now.
GLSA 200403-06
mips stable long ago.
