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

Re: OpenLDAP clients dump core in SSL mode (ITS#889)

del@babel.com.au wrote:
> Version: 2.0.7
> ldapsearch -H ldaps://<servername>/ -x
> also, Julio Sanchez Fernandez wrote:
> > It seems to fail in ldap_int_sasl_external in cyrus.c, possibly
> > because ld_defconn is garbage.
> >
> > But I don't quite understand why it is trying to do an external
> > sasl bind, if that is what it is doing...

I think that ldap_int_sasl_external is to set the sasl external ssf
value and auth_id to those of the external mechanism. 

It tries to access ld->ld_defconn->lconn_sasl_ctx which is not there

ldap_pvt_tls_start (which calls ldap_int_sasl_external) is also called
when establishing TLS. In this context, ld->ld_defconn is already valid.

But in a SSL connect, ld->ld_defconn is set to the return value of
ldap_new_connection in ldap_open_defconn. ldap_new_connection first
allocates lc to which ld->defconn is set. But ldap_new_connection calls
ldap_int_open_connection -> ldap_pvt_tls_start ->
ldap_int_sasl_external, which then tries to access the non existent

I suggest adding another parameter to ldap_pvt_tls_start which
explicitly holds ldap_conn and then calling ldap_int_sasl_external with
"LDAPConn *conn" instead of "LDAP *ld":

        LDAPConn *conn,
        const char * authid,
        ber_len_t ssf )
        int sc;
        sasl_conn_t *ctx = conn->lconn_sasl_ctx;

Norbert Klasen
DFN Directory Services                           tel: +49 7071 29 70335
ZDV, Universität Tübingen                        fax: +49 7071 29 5912
Wächterstr. 76, 72074 Tübingen              http://www.directory.dfn.de
Germany                             norbert.klasen@zdv.uni-tuebingen.de