I've got a weird problem with cyradm crashing (SIGSEGV) while performing
a simple 'lm'. After some ugly dedugging, I've isolated the problem
in lib/imclient.c.
It seems that the call to sasl_decode() in imclient_input() sets
wrongly 'plainlen' (to some value >1000000). Here's the code:
if (imclient->saslcompleted == 1) {
/* decrypt what we have */
if ((result = sasl_decode(imclient->saslconn, buf, len,
&plainbuf, &plainlen)) != SASL_OK) {
(void) shutdown(imclient->fd, 0);
}
if (plainlen == 0) return;
} else {
plainbuf = buf;
plainlen = len;
}
Is it a known problem of SASL 2.1.12? If so, please ignore this
bug report.
Some other facts:
1) cryadm crashes only on our production mailboxes database, which
is being converted both via ctl_mboxlist -d / ctl_mboxlist -u and
cvt_cyrusdb. That initially made me focus on format problems
(tried skiplist, db3, flat), conversion problems
(tried db3 tools, too), as a fresh install (empty mailboxes.db)
always worked.
In the end I've discovered it depends on the size of the server
response to the LIST command, i.e. on the number of folders and
their depth.
2) the old cyradm binary, from a 2.0.16 installation, never crashes.
(that made me turn to the client side instead of the server side)
The old binaries were compiled vs. SASL v.1.5.26 (shared), which has
been recently upgraded to 1.5.28.
3) behaviour depends on the SASL mech used to authenticate:
LOGIN: crashes
CRAM-MD5: crashes
DIGEST-MD5: works well
I can't test PLAIN, since cyradm can't do TLS. SRP crashes, too, but
it may be another kind of problem (see below). Please note DIGEST-MD5
it's the only mech in which sasl_decode is expected to do something.
I've traced it, it gets like 2kB of input and returns about 3kB of
'plainbuf'. AFAIK, for the other mechs sasl_decode() should only copy
the input "as is".
4) forcing the else part in the above code:
plainbuf = buf;
plainlen = len;
fixes the problem. Of course it is possible only if SASL uses
a mechs which does not provide any protection (when sasl_decode()
is just a noop, I think). This 'fix' works with CRAM-MD5 and LOGIN,
and of course breaks completely DIGEST-MD5 (and others, too, I guess).
Anyway it isolates the bug in sasl_decode(), apparently.
5) by extensive "Debugging with printf (TM)", I've discovered
the sasl_decode() misbehaviour (plainlen scrambling). It happens
if and only if the buffer is "large enough". This happens only when
the server response is large, of course. A short answer (2 or 3 test
mailbox) never triggers it.
"large enough" means both 4096 (the default) and 2048. 1440 works well.
1024 works too. I'm sorry I can't be more precise, but debugging
a perl application that gets some .so binary modules loaded which in
turn call some shared library functions (SASL) is beyond what I can
do in a decent timeframe B-).
6) the following patch fixes the problem, for all mechs but SRP.
I've never used SRP before, I've tried it only to collect more details
on this problem, so it may be a completely unrelated problem. All other
mechs do work.
--- cyrus-imapd-2.1.12/lib/imclient.c.buf1024 Wed Nov 6 21:43:26 2002
+++ cyrus-imapd-2.1.12/lib/imclient.c Thu Mar 27 20:40:47 2003
@@ -86,7 +86,7 @@
#include "iptostring.h"
/* I/O buffer size */
-#define IMCLIENT_BUFSIZE 4096
+#define IMCLIENT_BUFSIZE 1024
/* Command completion callback record */
struct imclient_cmdcallback {
sasl_decode() now gets called with a smaller buffer and plainlen
is always ok. Of course this is not a real fix, it just makes
cyradm work with the buggy sasl_decode().
7) the above (problems and fixes) has been tested on both a Red Hat
Linux 7.3 and 8.0. The SASL library has been compiled by me and upgraded
to 2.1.12 on both systems.
8) I haven't made any further investigation since I know very little of
SASL itself. I think that, if this isn't a known bug, I'd have to code
a little test program in C.
.TM.
--
____/ ____/ /
/ / / Marco Colombo
___/ ___ / / Technical Manager
/ / / ESI s.r.l.
_____/ _____/ _/ [EMAIL PROTECTED]
