cURL / Mailing Lists / curl-library / Single Mail


Re: openldap loops forever

From: Howard Chu <>
Date: Thu, 21 Jan 2016 19:39:01 +0000

> From: Patrick Monnerat <>
> Date: Thu, 21 Jan 2016 14:12:27 +0000
> Patrick Monnerat wrote:
>> I have just discovered a regression in curl ldap handling via openldap.c module:
>> The transfer is OK, but the end is not detected and curl loops forever.
> I've found the problem, though I did not resolve it.
> By default, openldap API now searches in referrals too.

That's not true. Referral chasing is disabled by default in all OpenLDAP
releases, it has never been enabled by default. If you're seeing it happen
here, that means you have an ldap.conf or ldaprc somewhere telling it to do so
- and you should probably change that.

> This is achieved
> by
opening secondary socket descriptors (internal to the openldap API). These
secondary descriptors are NOT monitored by curl's poll system and thus, data
available on these never trigger calls to ldap_recv() resulting in an endless
stalled dialog.

> Of course, this only occurs if there are referrals in the primary result set.
> One very easy solution would be to disable automatic referrals chasing
(LDAP_OPT_REFERRALS LDAP_OPT_OFF). The drawback would be we will not receive
entries from referrals.

Unfortunately, this would of course break things for someone who has
explicitly configured referral chasing ON.

> Else we should deal with multiple socket descriptors for a single easy
channel. I don't know if this is currently possible (pipelining?). Since there
is no ldap API to get secondary socket descriptors and because these sockets'
binds do not respect the primary socket's bind, it should probably be
necessary to process referrals chasing in the curl module rather than
automatically... lots of code to update or write.

At the very least, you must supply a rebind callback, otherwise the referrals
are chased anonymously. Note that all of this is quite a can of worms - in the
default case, you need to make sure you're talking to a trustworthy server.
Since a Simple Bind sends a plaintext username and password, it's a trivial
matter for an attacker to intercept a referral and capture your client
credentials. Defining what a "trustworthy server" is is an open question.

Ideally you should only chase referrals using secure credentials such as an
X.509 certificate or a Kerberos ticket. More ideally, you should never chase
referrals at all, a proper directory server will chain your requests for you
and never send referrals to a client.

> Comments are welcome!
> Patrick

   -- Howard Chu
   CTO, Symas Corp. 
   Director, Highland Sun
   Chief Architect, OpenLDAP
List admin:
Received on 2016-01-21