Re: sync_client segmentation fault when using TLS

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

 



Dietmar Rieder wrote:
Hi,

we just updated our master + replication servers from 2.3.13 to 2.3.16 and discovered, that the sync_client is dying with a segfault when it connects to the replication server which has set "allowplaintext: no".

We managed to trace down the problem and came up with the following patch against imap/backend.c to solve it.

Gernot & Didi

p.s.:
Allowing plaintext authentication by "allowplaintext: yes" on the replication server would also be an option as workarround ... but not for us :-)

--- backend.c.orig	Thu Apr 23 19:10:05 2009
+++ backend.c	Tue Jan 12 23:39:24 2010
@@ -93,7 +93,7 @@
resp = (automatic == AUTO_BANNER) ? prot->banner.resp : prot->capa_cmd.resp; - if (!automatic) {
+    if (!automatic && (prot->capa_cmd.cmd!=NULL)) {
 	/* no capability command */
 	if (!prot->capa_cmd.cmd) return NULL;
 	
@@ -449,7 +449,8 @@
     if ((server[0] != '/') ||
 	(strcmp(prot->sasl_service, "lmtp") &&
 	 strcmp(prot->sasl_service, "csync"))) {
-	char *mlist = xstrdup(mechlist); /* backend_auth is destructive */
+	char *mlist=NULL;
+	if (mechlist) mlist= xstrdup(mechlist); /* backend_auth is destructive */
if ((r = backend_authenticate(ret, prot, &mlist, userid,
 				      cb, auth_status))) {

As I mentioned in a previous post in this thread, I was having the same
problem at our site following a 2.3.13 to 2.3.16 upgrade, and tried the
patch included above.  As this appeared to introduce another problem, I
spent some time analyzing the situation and came up with the following,
similar patch (also included as an attachment), which only alters the
behavior of ask_capability in backend.c when invoked within sync_client instead of all callers. While I realize that this is probably not the best approach, it does address the problem at hand without requiring a deeper understanding best left to the developers and without the potential of introducing undesirable side effects on other components that rely on backend.c.


--- backend.c      2009-04-23 12:10:05.000000000 -0500
+++ backend.c   2010-03-30 15:58:22.000000000 -0500
@@ -93,7 +93,7 @@

       resp = (automatic == AUTO_BANNER) ? prot->banner.resp :
prot->capa_cmd.resp;

-    if (!automatic) {
+    if (!automatic && strcmp(prot->sasl_service, "csync")) {
          /* no capability command */
          if (!prot->capa_cmd.cmd) return NULL;

@@ -449,7 +449,8 @@
       if ((server[0] != '/') ||
          (strcmp(prot->sasl_service, "lmtp") &&
           strcmp(prot->sasl_service, "csync"))) {
-       char *mlist = xstrdup(mechlist); /* backend_auth is destructive */
+        char *mlist = NULL;
+       if (mechlist) mlist = xstrdup(mechlist); /* backend_auth is
destructive */

          if ((r = backend_authenticate(ret, prot, &mlist, userid,
                                        cb, auth_status))) {




There are really two problems affecting sync_client that were introduced by the new version, both of which are triggered when the sync_client attempts to authenticate to the sync_server. More on this later.

As I seem to be one of only two users on this list who reported this
problem, I'm led to believe that there's something about our two
installations that's unique compared to everyone else's.  To satisfy my
curiosity as to why such problem could go unnoticed by anyone else for several months I'd like to compare my setup with other list members who are using replication.

I tested 2.3.16 replication on the following platforms:

  Dell PE2950III dual quad core / 32 bit RHEL 4.7

  Dell PE2950III dual quad core / 32 bit RHEL 5.4

Relevant config snippets:

  From master /etc/cyrus.conf:

    syncclient       cmd="sync_client -r"

  From master /etc/imapd.conf:

    guid_mode: sha1
    sync_host: somehost.somedomain.tld
    sync_authname: csync
    sync_password: *********
    sync_log: 1
    sync_shutdown_file: /var/lib/imap/sync_shutdown

  From replica /etc/cyrus.conf:

     syncserver    cmd="sync_server" listen="csync"

  From replica /etc/imapd.conf:

    sasl_pwcheck_method: saslauthd
    sasl_mech_list: PLAIN
    allowplaintext: no
    sasl_minimum_layer: 128
    tls_cert_file: /etc/pki/tls/certs/cert.pem
    tls_ca_file: /etc/pki/tls/certs/chain.pem
    tls_key_file: /etc/pki/tls/private/key.pem
    tls_cipher_list: !ADH:MEDIUM:HIGH
    guid_mode: sha1

  From replica /etc/sysconfig/saslauthd:

    MECH=pam


The banner presented by sync_server:

    $ telnet localhost 2005
    Trying 127.0.0.1...
    Connected to localhost.localdomain (127.0.0.1).
    Escape character is '^]'.
    * STARTTLS
    * OK somehost.somedomain.tld Cyrus sync server v2.3.16


Observations:

  There are no mechs in the banner for ask_capability()
  to return, hence ask_capability() returns NULL mechlist.

  This causes backend_connect() to segfault when it tries to
  xstrdup() mechlist before calling backend_authenticate(), or
  rather when xstrdup() tries to strlen() a NULL string.

  This is the first of the two aforementioned problems.  Version
  2.3.13 did not copy mechlist prior to calling
  backend_authenticate(), so this problem did not exist.

  Once the xstrdup problem has been patched away, the second
  problem becomes apparent.  The behavior of ask_capability()
  has changed between 2.3.13 and 2.3.16.  Version 2.3.16
  of ask_capability() returns NULL immediately if automatic and
  prot->capa_cmd.cmd are logically false.  In
  this case, backend_authenticate() never obtains a
  mech following a STARTTLS and can therefore never authenticate.
  Version 2.3.13 ask_capability(), on the other hand, would proceed
  to parse the banner for mechs in the event that automatic and
  prot->capa_cmd.cmd are logically false.

  I felt this second issue was better addressed by limiting the patch
  in ask_capability() to affect only cases where prot->sasl_service
  is "csync", as it is less than obvious to me what
  undesireable effects might result from changing the behavior of
  ask_capability() for every caller without expending significantly
  more time studying the code and testing changes.  I leave the
  permanent fix in the far more capable hands of the developers.


How do the settings and the banner above differ from those on 2.3.16 installations where replication is working? Would anyone with a working installation be willing to compare theirs with mine?

Thanks.

--
___________________________________________________________________________
Raphael Jaffey                             E-mail: rjaffey@xxxxxxxxx
Director of Network Services
The Art Institute of Chicago                Voice: (312) 629-6543
111 S. Michigan Ave, Chicago, IL  60603       FAX: (312) 641-3406


diff -Naur cyrus-imapd-2.3.16.orig/imap/backend.c cyrus-imapd-2.3.16/imap/backend.c
--- cyrus-imapd-2.3.16.orig/imap/backend.c	2009-04-23 12:10:05.000000000 -0500
+++ cyrus-imapd-2.3.16/imap/backend.c	2010-03-30 15:58:22.000000000 -0500
@@ -93,7 +93,7 @@
 
     resp = (automatic == AUTO_BANNER) ? prot->banner.resp : prot->capa_cmd.resp;
 
-    if (!automatic) {
+    if (!automatic && strcmp(prot->sasl_service, "csync")) {
 	/* no capability command */
 	if (!prot->capa_cmd.cmd) return NULL;
 	
@@ -449,7 +449,8 @@
     if ((server[0] != '/') ||
 	(strcmp(prot->sasl_service, "lmtp") &&
 	 strcmp(prot->sasl_service, "csync"))) {
-	char *mlist = xstrdup(mechlist); /* backend_auth is destructive */
+        char *mlist = NULL;
+	if (mechlist) mlist = xstrdup(mechlist); /* backend_auth is destructive */
 
 	if ((r = backend_authenticate(ret, prot, &mlist, userid,
 				      cb, auth_status))) {
----
Cyrus Home Page: http://cyrusimap.web.cmu.edu/
Cyrus Wiki/FAQ: http://cyrusimap.web.cmu.edu/twiki
List Archives/Info: http://asg.web.cmu.edu/cyrus/mailing-list.html

[Index of Archives]     [Cyrus SASL]     [Squirrel Mail]     [Asterisk PBX]     [Video For Linux]     [Photo]     [Yosemite News]     [gtk]     [KDE]     [Gimp on Windows]     [Steve's Art]

  Powered by Linux