[Date Prev][Date Next] [Chronological] [Thread] [Top]

FW: Segfault with TLS



I have just verified the following bug report. The question is what exactly
should the fix be? Requiring a FQDN on the commandline makes TLS sessions
less convenient than plaintext sessions. Should we pull the FQDN out of
ldap.conf
when it is absent? Should we use the string "localhost"? (That solution
doesn't work because there's no way "localhost" will appear as one of the
valid
names in a server's certificate.) The simple fix is to insist that there is
a
valid FQDN on the commandline and just return an error if no name is given.

Comments?

-----Original Message-----
From: owner-openldap-software@OpenLDAP.org
[mailto:owner-openldap-software@OpenLDAP.org] On Behalf Of Howard Chu

The segfault occurs in the new ldap_pvt_tls_check_hostname which is doing
a strcasecmp with a NULL pointer. It is trying to compare the hostname
provided on the commandline against the hostname embedded in the server's
certificate, but since you didn't provide any hostname, this value was
NULL. The workaround is to use a valid hostname on the commandline, e.g.
	ldapsearch -H ldap://my.fqdn.com/ -x -Z
until the library is fixed.

  -- Howard Chu
  Chief Architect, Symas Corp.       Director, Highland Sun
  http://www.symas.com               http://highlandsun.com/hyc

> -----Original Message-----
> From: owner-openldap-software@OpenLDAP.org
> [mailto:owner-openldap-software@OpenLDAP.org]On Behalf Of Timm Essigke
> Sent: Wednesday, September 12, 2001 2:57 PM
> To: OpenLDAP-software@OpenLDAP.org
> Subject: Segfault with TLS
>
>
> Dear list,
>
> Client programs (ldapsearch, ldapadd, ldapmodify) segfault (no core!)
> with any encrypted
> connection to the LDAP server.
>
> The possible bug is very similar to ITS #889
>
> OpenLDAP 2.0.13 & 2.0.14
> OS: Linux (Suse 7.2)
>
> - make test works
>
> (slapd -d -1 -h "ldap:/// ldaps:///")
> - ldapsearch -H ldap:/// -x works
> - ldapsearch -H ldap:/// -I works via SASL/GSSAPI + Kerberos V
>
> - ldapsearch -H ldap:/// -x -Z   Segmentation fault
> - ldapsearch -H ldap:/// -x -ZZ  Segmentation fault
> - ldapsearch -H ldaps:/// -x     Segmentation fault
> ( - ldapsearch -H ldaps:/// -x -Z  Segmentation fault
>   - ldapsearch -H ldaps:/// -x -ZZ Segmentation fault )
>
> Debug output (without long HEX code = ...)
> daemon: activity on 1 descriptors
> daemon: new connection on 10
> daemon: conn=0 fd=10 connection from IP=127.0.0.1:33818 (IP=:: 31746)
> accepted.
> daemon: added 10r
> daemon: activity on:
> daemon: select: listen=6 active_threads=0 tvp=NULL
> daemon: select: listen=7 active_threads=0 tvp=NULL
> daemon: activity on 1 descriptors
> daemon: activity on: 10r
> daemon: read activity on 10
> connection_get(10)
> connection_get(10): got connid=0
> connection_read(10): checking for input on id=0
> TLS trace: SSL_accept:before/accept initialization
> tls_read: want=11, got=11
> ...
> TLS trace: SSL_accept:SSLv3 read client hello A
> TLS trace: SSL_accept:SSLv3 write server hello A
> TLS trace: SSL_accept:SSLv3 write certificate A
> TLS trace: SSL_accept:SSLv3 write server done A
> tls_write: want=970, written=970
> ...
> TLS trace: SSL_accept:SSLv3 flush data
> tls_read: want=5, got=5
>   0000:  16 03 01 00 86                                     .....
> tls_read: want=134, got=134
> ...
> TLS trace: SSL_accept:SSLv3 read client key exchange A
> tls_read: want=5, got=5
>   0000:  14 03 01 00 01                                     .....
> tls_read: want=1, got=1
>   0000:  01                                                 .
> tls_read: want=5, got=5
>   0000:  16 03 01 00 28                                     ....(
> tls_read: want=40, got=40
> ...
> TLS trace: SSL_accept:SSLv3 read finished A
> TLS trace: SSL_accept:SSLv3 write change cipher spec A
> TLS trace: SSL_accept:SSLv3 write finished A
> tls_write: want=51, written=51
> ...
> TLS trace: SSL_accept:SSLv3 flush data
> daemon: select: listen=6 active_threads=0 tvp=NULL
> daemon: select: listen=7 active_threads=0 tvp=NULL
> daemon: activity on 1 descriptors
> daemon: activity on: 10r
> daemon: read activity on 10
> connection_get(10)
> connection_get(10): got connid=0
> connection_read(10): checking for input on id=0
> ber_get_next
> tls_read: want=5, got=0
>
> ldap_read: want=1, got=0
>
> ber_get_next on fd 10 failed errno=0 (Success)
> connection_read(10): input error=-2 id=0, closing.
> connection_closing: readying conn=0 sd=10 for close
> connection_close: conn=0 sd=10
> daemon: removing 10
> conn=-1 fd=10 closed
> tls_write: want=29, written=29
>   0000:  15 03 01 00 18 1d 26 2b  23 de 12 72 00 50 18 8b
> ......&+#..r.P..
>   0010:  03 a1 e8 6a 1c 1f 5a 96  a3 d2 81 2c 15
> ...j..Z....,.
> TLS trace: SSL3 alert write:warning:close notify
> daemon: select: listen=6 active_threads=0 tvp=NULL
> daemon: select: listen=7 active_threads=0 tvp=NULL
> daemon: activity on 1 descriptors
> daemon: select: listen=6 active_threads=0 tvp=NULL
> daemon: select: listen=7 active_threads=0 tvp=NULL
>
> I use openssl-0.9.6b, cyrus-sasl-1.5.24 and krb5-1.2.2.
> All packages seem to work for their own and with Kerberos.
>
> Has anybody encountered the same problem?
> I couldn't find an appropriate patch. Have I missed it?
>
> TIA,
>
> Timm Essigke
>