(ITS#5259) SIGSEGV in slap_auxprop_store during SASL/OTP bind

[dwhite@olp.net]

Full_Name: Dan White
Version: 2.3.39
OS: Linux
URL: http://support.olp.net/ldap/log.txt
Submission from: (NULL) (65.161.252.42)


I'm experiencing crashes in slapd when attempting to bind via SASL using the OTP
mech.

I'm using openldap version 2.3.39 for both slapd and my ldap utils (ldapsearch).
I'm using the bdb backend.

I'm also using Debian Etch with the following versions of software:

Cyrus SASL 2.1.22(.dfsg1-8)
libdb 4.2.52(+dfsg-2)
libc6 2.3.6(.ds1-13etch2)

I've compiled cyrus sasl to use it's internal implementation of OTP, rather than
OPIE:

--enable-otp
(--with-opie is not enabled)

The problem I'm experiencing isn't when I successfully authenticate; that seems
to work fine. It's when I run an ldapsearch, but instead of entering an OTP
password, I press ctrl-c to cancel the search.

>From the shell, when I perform an LDAP search, all appears normal:

hiro:~# ldapsearch -Y OTP -U abrown@olp.net
SASL/OTP authentication started
Challenge: otp-md5 497 hi3182 ext
Please enter your one-time password:<ctrl-c>
hiro:~#

However my slapd process dies.

Here's a gdb backtrace of the server process:

...
Core was generated by `/usr/sbin/slapd'.
Program terminated with signal 11, Segmentation fault.
#0  0x080b448e in slap_auxprop_store (glob_context=0x0, sparams=0x820b2a0,
prctx=0x82351c0, user=0x820a148 "abrown@olp.net", ulen=14)
    at
/usr/src/build/openldap/openldap2.3-2.3.39/servers/slapd/sasl.c:478
478                             op.o_hdr =
conn->c_sasl_bindop->o_hdr;
(gdb) bt
#0  0x080b448e in slap_auxprop_store (glob_context=0x0, sparams=0x820b2a0,
prctx=0x82351c0, user=0x820a148 "abrown@olp.net", ulen=14)
    at
/usr/src/build/openldap/openldap2.3-2.3.39/servers/slapd/sasl.c:478
#1  0xb7eb17d7 in sasl_auxprop_store () from /usr/lib/libsasl2.so.2
#2  0xb7973c89 in otp_server_plug_init () from /usr/lib/sasl2/libotp.so.2
#3  0xb7ebde36 in sasl_server_new () from /usr/lib/libsasl2.so.2
#4  0xb7eb6194 in sasl_dispose () from /usr/lib/libsasl2.so.2
#5  0x080b2992 in slap_sasl_close (conn=0xb7ec3618) at
/usr/src/build/openldap/openldap2.3-2.3.39/servers/slapd/sasl.c:1331
#6  0x0806cf27 in connection_close (c=0xb75b1148) at
/usr/src/build/openldap/openldap2.3-2.3.39/servers/slapd/connection.c:715
#7  0x0806e116 in connection_read (s=12) at
/usr/src/build/openldap/openldap2.3-2.3.39/servers/slapd/connection.c:1458
#8  0x0806a49f in slapd_daemon_task (ptr=0x0) at
/usr/src/build/openldap/openldap2.3-2.3.39/servers/slapd/daemon.c:2468
#9  0xb7cd3240 in start_thread () from /lib/tls/i686/cmov/libpthread.so.0
#10 0xb7c674ae in clone () from /lib/tls/i686/cmov/libc.so.6
(gdb) quit

I've added a debug statement within slap_auxprop_store, so the openldap debug
information below will include some additional information about what's being
modified.

The output can be obtained from:

http://support.olp.net/ldap/log.txt

Notice the two lines:

Dec  3 13:39:06 hiro slapd[11134]: slap_auxprop_store [conn=3]: Getting ready to
set cmusaslsecretOTP to
md5^I0499^Ihi5935^I0e81b33e30182715^I00000000001196711046.
Dec  3 13:39:07 hiro slapd[11134]: slap_auxprop_store [conn=-1]: Getting ready
to set cmusaslsecretOTP to
md5^I0499^Ihi5935^I0e81b33e30182715^I00000000000000000000.

If I enter a good OTP password, I get this in my logs:

Dec  3 13:43:26 hiro slapd[11159]: slap_auxprop_store [conn=3]: Getting ready to
set cmusaslsecretOTP to
md5^I0499^Ihi5865^Iec8123986aec6550^I00000000001196711306.
Dec  3 13:44:26 hiro slapd[11159]: slap_auxprop_store [conn=3]: Getting ready to
set cmusaslsecretOTP to
md5^I0498^Ihi5865^Ic3570f027cf46ed0^I00000000000000000000.

If I enter an incorrect password, I get this:

Dec  3 13:45:21 hiro slapd[11159]: slap_auxprop_store [conn=4]: Getting ready to
set cmusaslsecretOTP to
md5^I0498^Ihi5865^Ic3570f027cf46ed0^I00000000001196711421.
Dec  3 13:45:22 hiro slapd[11159]: slap_auxprop_store [conn=4]: Getting ready to
set cmusaslsecretOTP to
md5^I0498^Ihi5865^Ic3570f027cf46ed0^I00000000000000000000.

So in the case where it's crashing, it appears the Cyrus SASL is attempting to
revert the OTP entry back to the previous version to "unlock" it. I assume that
the connection id of '-1' is relevant to the crash.

You should be able to reproduce this error with the following steps:

Compile SASL with OTP, but without OPIE

Configure a dummy SASL service configuration file to be used with saslpasswd2
below, e.g.:
    hiro:~# cat > /usr/lib/sasl2/test.conf <<EOF
    > auxprop_plugin: ldapdb
    > ldapdb_uri: ldapi:///
    > ldapdb_mech: EXTERNAL
    > EOF
    hiro:~#

Create a schema including an attribute of cmusaslsecretOTP, and create an entry
in the directory which can use this attribute.

Configure slapd.conf with the appropriate sasl configuration to convert both the
shell (root) user (connecting via ldapi:///) and the user specified in the
ldapsearch, for example:
    sasl-regexp "gidNumber=0\\\+uidNumber=0,cn=peercred,cn=external,cn=auth"
      cn=admin,dc=olp,dc=net

    sasl-regexp
      "uid=([^,]+),cn=otp,cn=auth"
      ldap:///ou=people,dc=olp,dc=net??one?(btcAltUid=$1)

Issue a saslpasswd2 to initialize the cmusaslsecretOTP attribute for the user:

    hiro:~# saslpasswd2 -a test -n abrown@olp.net
    Password:
    Again (for verification):

The cmusaslsecretOTP attribute should look something like:
    md5     0499    hi8351  1c19abc81f35dc63 00000000000000000000

opiekey can be used to convert the OTP challenge into the appropriate response.
For instance:

    hiro:~# ldapsearch -Y OTP -U abrown@olp.net
    SASL/OTP authentication started
    Challenge: otp-md5 498 hi8351 ext
    Please enter your one-time password:

Using opiekey to obtain response:

    dwhite@zek:~$ opiekey -5 -x 498 hi8351
    Using the MD5 algorithm to compute response.
    Reminder: Don't use opiekey from telnet or dial-in sessions.
    Enter secret pass phrase:
    556A 99B3 52FA CEB1

Feed the result back into ldapsearch for a successful bind.

To reproduce the bug, of course just kill the ldapsearch before entering any
response.