On Redhat Enterprise Linux 3, when I try to use LDAP (Port = 636 and hence with TLS),
FreeRadius seg faults within rlm_ldap. I have been following the various seg faults
for this module discussed recently (including on Fedora Core 2, etc), but this appears
to be a different problem to Bug #73. Without TLS, it works fine, but as soon as the
port is changed to 636 (or even another high port with tls_mode=yes), the seg fault
happens.
I am using FR version 1.0.0 on RHEL3 ES [OpenLDAP v2.0.27 (RH update 2.0.27-11),
OpenSSL v0.9.7a (RH update 0.9.7a-33.4)]. I have previously tried this with FR 0.9.0,
0.9.3 and 1.0.0pre3, with the same result. I also tried it on a vanilla RHEL3 ES
install with none of their updates - same result. There are no other OpenSSL
installations on the machine - I have tried this on fresh OS installs too to eliminate
any chance of this, to no avail. The LDDs on libldap, libldap_r and rlm_ldap are shown
at the bottom of this message, if needed.
After compiling all components locally with debug, I ran it under GDB ("gdb radiusd",
and then "run -X"). It shows that the seg fault happens at the line 845 in tls.c
within the OpenLDAP library libldap. The line is "method->ext_free(alt);". The last
few lines of the FR debug trace and the GDB backtrace are shown below:
rlm_ldap: (re)connect to ldap1.dimmy.someplace.com:636, authentication 0
rlm_ldap: setting TLS mode to 1
rlm_ldap: setting TLS CACert File to /etc/raddb/certs/demoCA/rootca.ca.pem
rlm_ldap: bind as cn=luuser,ou=users,dc=dimmy,dc=someplace,dc=com/password to
ldap1.dimmy.someplace.com:636
ldap_bind
ldap_simple_bind
ldap_sasl_bind
ldap_send_initial_request
ldap_new_connection
ldap_int_open_connection
ldap_connect_to_host: ldap1.dimmy.someplace.com
ldap_new_socket: 10
ldap_prepare_socket: 10
ldap_connect_to_host: Trying 10.24.10.4:636
ldap_connect_timeout: fd: 10 tm: 5 async: 0
ldap_ndelay_on: 10
ldap_is_sock_ready: 10
ldap_ndelay_off: 10
ldap_int_sasl_open: host=ldap1.dimmy.someplace.com
TLS trace: SSL_connect:before/connect initialization
TLS trace: SSL_connect:SSLv2/v3 write client hello A
TLS trace: SSL_connect:SSLv3 read server hello A
TLS certificate verification: depth: 1, subject: <removed>, issuer: <removed>
TLS certificate verification: depth: 0, subject: <removed>, issuer: <removed>
TLS trace: SSL_connect:SSLv3 read server certificate A
TLS trace: SSL_connect:SSLv3 read server certificate request A
TLS trace: SSL_connect:SSLv3 read server done A
TLS trace: SSL_connect:SSLv3 write client certificate A
TLS trace: SSL_connect:SSLv3 write client key exchange A
TLS trace: SSL_connect:SSLv3 write change cipher spec A
TLS trace: SSL_connect:SSLv3 write finished A
TLS trace: SSL_connect:SSLv3 flush data
TLS trace: SSL_connect:SSLv3 read finished A
Program received signal SIGSEGV, Segmentation fault.
[Switching to Thread -1222204608 (LWP 20379)]
0x00000000 in ?? ()
(gdb) bt
#0 0x00000000 in ?? ()
#1 0xb720a086 in ldap_pvt_tls_check_hostname (s=0xb7571de0, name=0x817ceb0
"ldap1.dimmy.someplace.com")
at tls.c:845
#2 0xb720a7ce in ldap_int_tls_start (ld=0x817cb40, conn=0x817d358, srv=0xb7571de0) at
tls.c:1122
#3 0xb71f07af in ldap_int_open_connection (ld=0x817cb40, conn=0x817d358,
srv=0x817ced8, async=135780240) at open.c:300
#4 0xb71fef2b in ldap_new_connection (ld=0x817cb40, srvlist=0x817ced8, use_ldsb=1,
connect=1, bind=0x0) at request.c:258
#5 0xb71f01e1 in ldap_open_defconn (ld=0x817cb40) at open.c:29
#6 0xb71feb5e in ldap_send_initial_request (ld=0x817cb40, msgtype=96,
dn=0x815ce40 "cn=luuser,ou=users,dc=dimmy,dc=someplace,dc=com", ber=0x817cf18) at
request.c:90
#7 0xb71f7b98 in ldap_sasl_bind (ld=0x817cb40,
dn=0x815ce40 "cn=luuser,ou=users,dc=dimmy,dc=someplace,dc=com", mechanism=0x0,
cred=0xbfff6350,
sctrls=0xb7571de0, cctrls=0xb7571de0, msgidp=0xbfff634c) at sasl.c:149
#8 0xb71f854c in ldap_simple_bind (ld=0x817cb40, dn=0xb7571de0 "U", passwd=0x815da38
"password") at sbind.c:78
#9 0xb71ef909 in ldap_bind (ld=0x817cb40, dn=0xb7571de0 "U", passwd=0xb7571de0 "U",
authmethod=128) at bind.c:67
#10 0xb723b0bd in ldap_connect (instance=0x815d958,
dn=0x815ce40 "cn=luuser,ou=users,dc=dimmy,dc=someplace,dc=com", password=0x815da38
"password",
auth=0, result=0xbfff6408) at rlm_ldap.c:1684
#11 0xb72382c9 in perform_search (instance=0x815d958, conn=0x815dcf0,
search_basedn=0xbfff64b0 "dc=dimmy,dc=someplace,dc=com", scope=2,
filter=0xbfff6cb0 "(cn=someuser)",
attrs=0xbfff64a8, result=0xbfff6498) at rlm_ldap.c:694
#12 0xb723876e in ldap_groupcmp (instance=0x815d958, req=0x817bf18, request=0x817c018,
check=0x8176760,
check_pairs=0x81764d0, reply_pairs=0x817c010) at rlm_ldap.c:846
#13 0x0804fdc7 in paircompare (req=0x817bf18, request=0x817c018, check=0x819ca70,
check_pairs=0x81764d0,
reply_pairs=0x817c010) at valuepair.c:97
#14 0x0804ff61 in paircmp (req=0x817bf18, request=0x817c018, check=0x81764d0,
reply=0x817c010) at valuepair.c:322
#15 0xb71bd030 in file_authorize (instance=0xb7571de0, request=0x817bf18) at
rlm_files.c:321
#16 0x0805507a in call_modsingle (component=1, sp=0x8163b00, request=0x817bf18,
default_result=6) at modcall.c:219
#17 0x080551d6 in modcall (component=1, c=0x8163b00, request=0x817bf18) at
modcall.c:344
#18 0x08055161 in call_modgroup (component=1, g=0xb7571de0, request=0x817bf18,
default_result=6) at modcall.c:252
#19 0x0805524d in modcall (component=1, c=0x8160bb0, request=0x817bf18) at
modcall.c:335
#20 0x08054d58 in module_authorize (autz_type=0, request=0xb7571de0) at modules.c:899
#21 0x08051d98 in rad_authenticate (request=0x817bf18) at auth.c:552
#22 0x0804d695 in rad_respond (request=0x817bf18, fun=0x8051d28 <rad_authenticate>) at
radiusd.c:1672
#23 0x0804d279 in main (argc=135773976, argv=0x8051d28) at radiusd.c:1457
I don't really know the code involved, but had an observation (which may be completely
off track - anyway, here goes...). What seems strange in this is the parameter "s" to
ldap_pvt_tls_check_hostname. You can see this is a pointer (void *s) and the address
is 0xb7571de0. This location seems to have got screwed up when ldap_connect in
rlm_ldap.c (line 1684) called ldap_bind (LIBLDAP bind.c:67). This can be seen above at
frames #9 and #10. Within rlm_ldap's ldap_connect, the variables dn and password are
correct, but when they are passed to ldap_bind, they become NULL (as seen by stepping
through the execution). In frame #9 above, they can both be seen as "U", and are the
same address 0xb7571de0 we saw earlier!
LDDs on relevant libraries:
ldd /usr/lib/libldap.so
libsasl.so.7 => /usr/lib/libsasl.so.7 (0xb75c9000)
libssl.so.4 => /lib/libssl.so.4 (0xb7587000)
libcrypto.so.4 => /lib/libcrypto.so.4 (0xb7495000)
liblber.so.2 => /usr/lib/liblber.so.2 (0xb748a000)
libc.so.6 => /lib/tls/libc.so.6 (0xb7352000)
libgdbm.so.2 => /usr/lib/libgdbm.so.2 (0xb734b000)
libdl.so.2 => /lib/libdl.so.2 (0xb7348000)
libcrypt.so.1 => /lib/libcrypt.so.1 (0xb731a000)
libpam.so.0 => /lib/libpam.so.0 (0xb7312000)
libresolv.so.2 => /lib/libresolv.so.2 (0xb7300000)
libgssapi_krb5.so.2 => /usr/kerberos/lib/libgssapi_krb5.so.2 (0xb72ed000)
libkrb5.so.3 => /usr/kerberos/lib/libkrb5.so.3 (0xb728f000)
libcom_err.so.3 => /usr/kerberos/lib/libcom_err.so.3 (0xb728d000)
libk5crypto.so.3 => /usr/kerberos/lib/libk5crypto.so.3 (0xb727c000)
libz.so.1 => /usr/lib/libz.so.1 (0xb726e000)
/lib/ld-linux.so.2 => /lib/ld-linux.so.2 (0x80000000)
liblaus.so.1 => /lib/liblaus.so.1 (0xb726b000)
ldd /usr/lib/libldap_r.so
libsasl.so.7 => /usr/lib/libsasl.so.7 (0xb75c5000)
libssl.so.4 => /lib/libssl.so.4 (0xb7583000)
libcrypto.so.4 => /lib/libcrypto.so.4 (0xb7491000)
liblber.so.2 => /usr/lib/liblber.so.2 (0xb7486000)
libc.so.6 => /lib/tls/libc.so.6 (0xb734e000)
libgdbm.so.2 => /usr/lib/libgdbm.so.2 (0xb7347000)
libdl.so.2 => /lib/libdl.so.2 (0xb7343000)
libcrypt.so.1 => /lib/libcrypt.so.1 (0xb7316000)
libpam.so.0 => /lib/libpam.so.0 (0xb730e000)
libresolv.so.2 => /lib/libresolv.so.2 (0xb72fc000)
libgssapi_krb5.so.2 => /usr/kerberos/lib/libgssapi_krb5.so.2 (0xb72e9000)
libkrb5.so.3 => /usr/kerberos/lib/libkrb5.so.3 (0xb728b000)
libcom_err.so.3 => /usr/kerberos/lib/libcom_err.so.3 (0xb7288000)
libk5crypto.so.3 => /usr/kerberos/lib/libk5crypto.so.3 (0xb7278000)
libz.so.1 => /usr/lib/libz.so.1 (0xb726a000)
/lib/ld-linux.so.2 => /lib/ld-linux.so.2 (0x80000000)
liblaus.so.1 => /lib/liblaus.so.1 (0xb7267000)
ldd /usr/lib/rlm_ldap.so
libsasl.so.7 => /usr/lib/libsasl.so.7 (0xb75ea000)
libcrypto.so.4 => /lib/libcrypto.so.4 (0xb74eb000)
libssl.so.4 => /lib/libssl.so.4 (0xb74b6000)
liblber.so.2 => /usr/lib/liblber.so.2 (0xb74ab000)
libldap_r.so.2 => /usr/lib/libldap_r.so.2 (0xb747d000)
libnsl.so.1 => /lib/libnsl.so.1 (0xb7468000)
libresolv.so.2 => /lib/libresolv.so.2 (0xb7455000)
libpthread.so.0 => /lib/tls/libpthread.so.0 (0xb7445000)
libc.so.6 => /lib/tls/libc.so.6 (0xb730d000)
libgdbm.so.2 => /usr/lib/libgdbm.so.2 (0xb7306000)
libdl.so.2 => /lib/libdl.so.2 (0xb7303000)
libcrypt.so.1 => /lib/libcrypt.so.1 (0xb72d6000)
libpam.so.0 => /lib/libpam.so.0 (0xb72cd000)
libgssapi_krb5.so.2 => /usr/kerberos/lib/libgssapi_krb5.so.2 (0xb72ba000)
libkrb5.so.3 => /usr/kerberos/lib/libkrb5.so.3 (0xb725c000)
libcom_err.so.3 => /usr/kerberos/lib/libcom_err.so.3 (0xb725a000)
libk5crypto.so.3 => /usr/kerberos/lib/libk5crypto.so.3 (0xb724a000)
libz.so.1 => /usr/lib/libz.so.1 (0xb723c000)
/lib/ld-linux.so.2 => /lib/ld-linux.so.2 (0x80000000)
liblaus.so.1 => /lib/liblaus.so.1 (0xb7238000)
NOTICE
This e-mail and any attachments are confidential and may contain copyright material of
Macquarie Bank or third parties. If you are not the intended recipient of this email
you should not read, print, re-transmit, store or act in reliance on this e-mail or
any attachments, and should destroy all copies of them. Macquarie Bank does not
guarantee the integrity of any emails or any attached files. The views or opinions
expressed are the author's own and may not reflect the views or opinions of Macquarie
Bank.
-
List info/subscribe/unsubscribe? See http://www.freeradius.org/list/users.html
