[Date Prev][Date Next]
Re: ldap_bind_st() call
Thomas Egerer wrote:
I am currently dealing with a problem in a third-party application
using openldap to retrieve CRLs. We are evaluating this piece of
software for possible vulnerabilities. One of the risk arises from
a possible DoS-attack involving the aforementioned CRL-retrieval.
Our scenario involves an attacker being able to hijack the LDAP-
server delivering the CRLs and replacing the actual LDAP-application
by a hand-crafted one which accepts connection attempts on port 389
and then does nothing. As a result the application being evaluated
is rendered unusable stalling forever while trying to download the
The reason for this behavior is the function call
ldap_simple_bind_s() being used to connect to the server. While we
are able to control the actual tcp connect and the retrieval of the
CRL using LDAP_OPT_NETWORK_TIMEOUT and LDAP_OPT_TIMEOUT, there
seems no option to use something like a ldap_bind_st()- function.
You appear to be using a very old version of OpenLDAP then. The
LDAP_OPT_TIMEOUT setting will timeout any synchronous request, and has done so
since early 2007 at least.
A mailinglist-entry back from 2002 suggested the implementation
of a custom ldap_bind_st()-function, which I did using ldap_bind()
and ldap_result(). Yet, me efforts were in vain as I could not
retrieve the ld_error-member from LDAP-structure since it's an
That's what ldap_get_option(,LDAP_OPT_RESULT_CODE,) is for.
I finally ended up with a custom function which
essentially does what I want, but I cannot figure out
To sum it up: any chance to get this upstream?
No. The current code already works as desired.
-- Howard Chu
CTO, Symas Corp. http://www.symas.com
Director, Highland Sun http://highlandsun.com/hyc/
Chief Architect, OpenLDAP http://www.openldap.org/project/