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.