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

Re: ldap_bind_st() call

Thomas Egerer wrote:

Hello *,

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
CRL.
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
opaque struct.


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/