Segfault in openldap while using ldaps

[monnerat]

I did this

curl -k --cert-type P12 --cert mycert.p12:password 'ldaps://localhost/?supportedSASLMechanisms?base?(objectclass=*)'
After correct output, curl segfaults while in ldap_unbind_ext called by ldap_disconnect.
This is the ldapsb_tls problem we shortly discussed at #6518 (comment) and is related to the conn->data removal.

I expected the following

Clean termination

curl/libcurl version

curl 7.76.0-DEV (x86_64-pc-linux-gnu) libcurl/7.76.0-DEV OpenSSL/1.1.1i-fips zlib/1.2.11 brotli/1.0.9 zstd/1.4.7 libidn2/2.3.0 libpsl/0.21.1 (+libidn2/2.3.0) iconv libssh/0.9.5/openssl/zlib nghttp2/1.43.0 librtmp/2.3 libgsasl/1.8.1
Release-Date: [unreleased]
Protocols: dict file ftp ftps gopher gophers http https imap imaps ldap ldaps mqtt pop3 pop3s rtmp rtsp scp sftp smb smbs smtp smtps telnet tftp
Features: alt-svc AsynchDNS brotli CharConv Debug gsasl GSS-API HTTP2 HTTPS-proxy IDN IPv6 Kerberos Largefile libz NTLM NTLM_WB PSL SPNEGO SSL TLS-SRP TrackMemory UnixSockets zstd

operating system

Linux patrick.monnerat 5.10.18-200.fc33.x86_64 #1 SMP Tue Feb 23 22:06:05 UTC 2021 x86_64 x86_64 x86_64 GNU/Linux

[cvengler]

I can reproduce with 24f850f on OpenBSD-current

eengler@openbsd:~/src/curl$ src/curl ldaps://db.debian.org/ 
DN: 
        objectClass: top
        objectClass: OpenLDAProotDSE


Segmentation fault (core dumped) 

[cvengler]

I did some investigation on it and it turns out that the following line tries to access an item from a NULL pointer:

struct ldapconninfo *li = conn->proto.ldapc;

The problem is that conn (data->conn) is NULL. However data itself is set, just not conn.

I might find time to write a patch for it this weekend but I can't promise anything. Will post more updates regarding it soon.

[monnerat]

I might find time to write a patch for it this weekend

I chased this down too and IMHO it's not as simple as it looks: data passed to ldap_disconnect is not the same as the one latched for ldapsb_tls. Daniel and me faced the same kind of problem in openssl while removing conn->data occurrences and we've made several unsuccessful trials before Daniel finally resolved it by a hack.

See #6518 (comment), #6446 (comment) and f2f91ac.

[cvengler]

Okay I spent some time this morning inspecting it but I see myself unable to do it unfortunately. The problem is indeed much bigger

[monnerat]

@bagder : thanks for fix. This effectively suppresses the segfault, but I wonder if the way it's done would'nt close the connection prematurely with regards to the LDAP protocol. I did not check, but the unbindRequest is probably not transmitted.

[bagder]

(This doesn't just suppress the segfault, it fixes the function to use the correct pointer and only use it if it is (still) valid.)

That's a slightly different but possibly still important issue: since the connection is already gone when ldap_disconnect is called the final actions are probably never done. I honestly don't know how important that is for users or servers.

The only proper way we can get this in order is to introduce an LDAP test server to the test suite and a few tests to make sure that curl speaks the protocol correctly. Easier said than done.

[monnerat]

(This doesn't just suppress the segfault, it fixes the function to use the correct pointer and only use it if it is (still) valid.)

It seems you set the pointer to NULL: in ldap_disconnect:
ber_sockbuf_add_io(sb, &ldapsb_tls, LBER_SBIOD_LEVEL_TRANSPORT, NULL);
This disables effective io.

The only proper way we can get this in order is to introduce an LDAP test server to the test suite and a few tests to make sure that curl speaks the protocol correctly. Easier said than done.

I already dreamed of it: that's another story!

[bagder]

It seems you set the pointer to NULL: in ldap_disconnect:

Yes, because when we disconnect LDAP there is no longer any transfer associated to it...