See mail below from Bron Gondwana <brong@fastmail.fm>. This issue is semi-public (patch committed to public scm repository, not published yet). I'll bump to 2.3.14-r3 soonish and like to see this version marked as stable. ##--> Hi, I'm emailing you to give you a heads-up because you maintain packages of the Cyrus email server. CMU will be making an announcement once they've got new packages ready to go. I discovered a buffer overflow bug in sieve that one of our users accidentally triggered, but which looks easily exploitable by anyone who can create a sieve script and cause it to be executed. I'll paste in the content of the advisory that I wrote up for CMU, and the patch (which you will also see has been applied to CVS for both 2.3 and 2.2) If you can think of any other maintainers who need to be told, let me know! I've got redhat, debian, freebsd and gentoo here I think, plus Simon who maintains his own separate RPM set. I couldn't figure out who in the Solaris world to contact. Regards, Bron. ================ Incorrect use of sizeof() on a character pointer rather than a character buffer caused negative lengths to be passed to snprintf, which were then converted to unsigned values, meaning that the snprintf statements were effectively unbounded. A sieve script containing either a single long rejection message or a large enough number of shorter actions causes the action_string buffer to overflow by an arbitrary amount when processing an incoming email. The content of the overflow is entirely determinable by the author of the sieve script. The content of the incoming email has no influence on the exploit other than determining which sieve rules are executed. The exploit is only influenced by the content of the sieve script. While it is trivial for a user message to cause a crash, an exploit would require an authenticated user to be actively malicious, so random emails from the internet are not a risk if none of your users have created sieve scripts that can cause a large enough set of action items to be "printed" to the actions_string variable. This exploit allows privilege escalation by any user able to create a sieve script and have it executed by an email delivery. The attacker gains full access as the "cyrus" operating system user, including the ability to read and modify the emails of all other users on the server. <--##
Candidate for stabilization: =net-mail/cyrus-imapd-2.3.14-r3
Setting permissions.
Arch Security Liaisons, please test the attached ebuild mark it stable. (Semi-public means you can commit to CVS) Target keywords : "amd64 hppa ppc ppc64 sparc x86" CC'ing current Liaisons: amd64 : keytoaster, chainsaw hppa : jer ppc : josejx, ranger ppc64 : josejx, ranger sparc : armin76, tcunha x86 : fauli, maekke
+ 07 Sep 2009; <chainsaw@gentoo.org> cyrus-imapd-2.3.14-r3.ebuild: + Marked stable on AMD64 as requested by Tobias Scherbaum + <dertobi123@gentoo.org> in bug #283596. Tested as a secure IMAP + (IMAPS/mandatory TLS) provider with inbound mail over LMTP.
checking for prop_get in -lsasl2... no configure: error: Cannot continue without libsasl2. I remerge cyrus-sasl to be sure...
Created attachment 203366 [details] config log [hppa,fail] (In reply to comment #5) > checking for prop_get in -lsasl2... no > configure: error: Cannot continue without libsasl2. > > I remerge cyrus-sasl to be sure... That isn't the first error (but the first fatal one).
now public. Tobias, can you please look into the compile errors before we readd arches? Thanks!
CVE-2009-2632 (http://nvd.nist.gov/nvd.cfm?cvename=CVE-2009-2632): Buffer overflow in the SIEVE script component (sieve/script.c) in cyrus-imapd in Cyrus IMAP Server 2.2.13 and 2.3.14 allows local users to execute arbitrary code and read or modify arbitrary messages via a crafted SIEVE script, related to the incorrect use of the sizeof operator for determining buffer length, combined with an integer signedness error.
(In reply to comment #7) > now public. Tobias, can you please look into the compile errors before we readd > arches? Thanks! > I can't reproduce the failure on hppa or amd64.
(In reply to comment #9) > (In reply to comment #7) > > now public. Tobias, can you please look into the compile errors before we readd > > arches? Thanks! > > > > I can't reproduce the failure on hppa or amd64. > and works for me on ppc, too. Some more information on that failures would be nice ...
There's a config.log attached to the bug, does not help? I'm ccing fauli and jer, maybe they habe some more info.
Created attachment 204117 [details] emerge --info [hppa]
Obviously something is changing LDFLAGS from this LDFLAGS="-Wl,-O1" to this (as it is used in the configure script): LDFLAGS='-L/usr/lib /usr/lib -Wl,-O1' [ebuild N ] net-mail/cyrus-imapd-2.3.14-r3 USE="kerberos nntp pam sieve snmp ssl tcpd -idled -kolab -replication" 0 kB However, configure succeeds and when I choose USE="-kerberos" so that should narrow the scope of the problem quite a bit.
Created attachment 204483 [details, diff] revised fix-db-rpath patch The original fix-db-rpath patch assumes that $andrew_runpath_switch = none, but that value isn't set anywhere in configure or elsewhere, so with the current patch LDFLAGS gets erroneously set to include /usr/lib, as $andrew_runpath_switch is unset: LDFLAGS="-L$1 $andrew_runpath_switch$1 ${LDFLAGS}" This patch removes the (unneeded) check for $andrew_runpath_switch and makes cyrus-imapd compile fine.
Created attachment 204485 [details, diff] Correct whitespace, file paths
(In reply to comment #15) > Created an attachment (id=204485) [edit] > Correct whitespace, file paths > In CVS. Thanks! :)
Let's try again. Add arches?
(In reply to comment #17) > Let's try again. Add arches? > uhrm, yeah
(In reply to comment #18) > (In reply to comment #17) > > Let's try again. Add arches? > > > > uhrm, yeah Stable for HPPA.
### Making all in /var/tmp/portage/net-mail/cyrus-imapd-2.3.14-r3/work/cyrus-imapd-2.3.14/imtest make[1]: Entering directory `/var/tmp/portage/net-mail/cyrus-imapd-2.3.14-r3/work/cyrus-imapd-2.3.14/imtest' i686-pc-linux-gnu-gcc -c -I.. -I./../lib -I../com_err/et -DHAVE_CONFIG_H -O2 -march=i686 -pipe imtest.c imtest.c: In function ‘main’: imtest.c:2529: error: ‘tls_conn’ undeclared (first use in this function) imtest.c:2529: error: (Each undeclared identifier is reported only once imtest.c:2529: error: for each function it appears in.) imtest.c:2531: error: ‘SSL_SENT_SHUTDOWN’ undeclared (first use in this function) imtest.c:2531: error: ‘SSL_RECEIVED_SHUTDOWN’ undeclared (first use in this function) make[1]: *** [imtest.o] Error 1 make[1]: Leaving directory `/var/tmp/portage/net-mail/cyrus-imapd-2.3.14-r3/work/cyrus-imapd-2.3.14/imtest' make: *** [all] Error 1 This is without USE=ssl.
ppc64 done
(In reply to comment #20) > ### Making all in > /var/tmp/portage/net-mail/cyrus-imapd-2.3.14-r3/work/cyrus-imapd-2.3.14/imtest > make[1]: Entering directory > `/var/tmp/portage/net-mail/cyrus-imapd-2.3.14-r3/work/cyrus-imapd-2.3.14/imtest' > i686-pc-linux-gnu-gcc -c -I.. -I./../lib -I../com_err/et -DHAVE_CONFIG_H > -O2 -march=i686 -pipe imtest.c > imtest.c: In function ‘main’: > imtest.c:2529: error: ‘tls_conn’ undeclared (first use in this function) > imtest.c:2529: error: (Each undeclared identifier is reported only once > imtest.c:2529: error: for each function it appears in.) > imtest.c:2531: error: ‘SSL_SENT_SHUTDOWN’ undeclared (first use in this > function) > imtest.c:2531: error: ‘SSL_RECEIVED_SHUTDOWN’ undeclared (first use in this > function) > make[1]: *** [imtest.o] Error 1 > make[1]: Leaving directory > `/var/tmp/portage/net-mail/cyrus-imapd-2.3.14-r3/work/cyrus-imapd-2.3.14/imtest' > make: *** [all] Error 1 > > This is without USE=ssl. > That's a regression?
(In reply to comment #22) > That's a regression? you should know that =) no it's not a regression.
(In reply to comment #23) > (In reply to comment #22) > > That's a regression? > > you should know that =) > no it's not a regression. > If it's not a regression it's ok to ignore this issue for now and get this one marked as stable *now*. It's still a security issue ...
x86 stable then.
sparc stable
Marked ppc stable.
GLSA request filed.
This issue was resolved and addressed in GLSA 201110-16 at http://security.gentoo.org/glsa/glsa-201110-16.xml by GLSA coordinator Tim Sammut (underling).
