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.