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.
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. I finally ended up with a custom function which essentially does what I want, but I cannot figure out if it's due to a bind-timeout or some other reason since ldap_result() returns -1 on failure and 0 otherwise, not the actual error code. Bottom line is, I'm back where I started: wondering why there is no such a function in openldap *and* if is there any chance getting the one that I wrote -- it's added below -- upstream. I know that ldap_bind_s is deprecated in favour of ldap_sasl_bind_s which I could also extend by a ldap_sasl_bind_st function, but I do not want to put any more effort in something being deemed to fail from the start. To sum it up: any chance to get this upstream?
Cheers
Thomas
diff --git a/include/ldap.h b/include/ldap.h index 3f0c1c4..dc3a48c 100644 --- a/include/ldap.h +++ b/include/ldap.h @@ -1270,6 +1270,15 @@ ldap_bind_s LDAP_P(( /* deprecated, use ldap_sasl_bind_s */ LDAP_CONST char *cred, int authmethod ));
+LDAP_F( int ) +ldap_bind_st LDAP_P(( + LDAP *ld, + LDAP_CONST char *who, + LDAP_CONST char *cred, + int authmethod, + struct timeval *timeout, + LDAPMessage **result )); + /* * in sbind.c: */ diff --git a/libraries/libldap/bind.c b/libraries/libldap/bind.c index 875bd69..303ead1 100644 --- a/libraries/libldap/bind.c +++ b/libraries/libldap/bind.c @@ -125,3 +125,32 @@ ldap_bind_s( return( ld->ld_errno = LDAP_AUTH_UNKNOWN ); } } + +int ldap_bind_st( + LDAP *ld, + LDAP_CONST char *dn, + LDAP_CONST char *passwd, + int authmethod, + struct timeval *timeout, + LDAPMessage **res ) +{ + int msgid; + + *res = NULL; + + Debug( LDAP_DEBUG_TRACE, "ldap_bind_st\n", 0, 0, 0 ); + + if ( (msgid = ldap_bind( ld, dn, passwd, authmethod )) == -1 ) + return( ld->ld_errno ); + + if ( ldap_result( ld, msgid, LDAP_MSG_ALL, timeout, res ) == -1 || !*res ) + return( ld->ld_errno ); + + if ( ld->ld_errno == LDAP_TIMEOUT ) { + (void) ldap_abandon( ld, msgid ); + ld->ld_errno = LDAP_TIMEOUT; + return( ld->ld_errno ); + } + + return( ldap_result2error( ld, *res, 0 ) ); +}
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.
On 06/24/2011 09:15 PM, Howard Chu schrobtete:
You appear to be using a very old version of OpenLDAP then.
This is correct, I am currently using openldap 2.1.30, still...
The LDAP_OPT_TIMEOUT setting will timeout any synchronous request, and has done so since early 2007 at least.
... I cannot confirm this. Even when I use openldap 2.4.23 I can reproduce my DoS-scenario by starting a 'nc -l localhost -p 389' and performing an 'ldapsearch -l 5 -h localhost ...' which ends up in an unresponsive ldapsearch.
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.
Thanks, that was what I was looking 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.
I don't see that.
Regards
Thomas
Thomas Egerer wrote:
On 06/24/2011 09:15 PM, Howard Chu schrobtete:
You appear to be using a very old version of OpenLDAP then.
This is correct, I am currently using openldap 2.1.30, still...
You're supposed to provide your version info at the *beginning* of the discussion. OpenLDAP 2.1 was obsoleted in 2004.
The LDAP_OPT_TIMEOUT setting will timeout any synchronous request, and has done so since early 2007 at least.
... I cannot confirm this. Even when I use openldap 2.4.23 I can reproduce my DoS-scenario by starting a 'nc -l localhost -p 389' and performing an 'ldapsearch -l 5 -h localhost ...' which ends up in an unresponsive ldapsearch.
The "-l" option to ldapsearch sets the Search Request time limit, which is not the same as the API timeout that LDAP_OPT_TIMEOUT controls.
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.
I don't see that.
You're looking at the wrong thing.
Thomas Egerer wrote:
On 06/24/2011 09:15 PM, Howard Chu schrobtete:
You appear to be using a very old version of OpenLDAP then.
This is correct, I am currently using openldap 2.1.30, still...
In the future please learn to read the web site of the open source project you're dealing with before posting. Specifically this
http://www.openldap.org/devel/contributing.html
Note the requirement of using up-to-date source code before making any contribution. Otherwise you just waste everyone's time raising questions that were mooted years ago.
On 06/27/2011 11:58 AM, Howard Chu schrobtete:
Thomas Egerer wrote:
On 06/24/2011 09:15 PM, Howard Chu schrobtete:
You appear to be using a very old version of OpenLDAP then.
This is correct, I am currently using openldap 2.1.30, still...
You're supposed to provide your version info at the *beginning* of the discussion. OpenLDAP 2.1 was obsoleted in 2004.
You're right, my bad. This mail refers to the current git-version of openldap (052ac2f ITS#6828 silence warning in prev commit).
The LDAP_OPT_TIMEOUT setting will timeout any synchronous request, and has done so since early 2007 at least.
... I cannot confirm this. Even when I use openldap 2.4.23 I can reproduce my DoS-scenario by starting a 'nc -l localhost -p 389' and performing an 'ldapsearch -l 5 -h localhost ...' which ends up in an unresponsive ldapsearch.
The "-l" option to ldapsearch sets the Search Request time limit, which is not the same as the API timeout that LDAP_OPT_TIMEOUT controls.
As far as I can read from the default value which is controlled by the LDAP_OPT_TIMEOUT option is -1 which means an infinite waiting time. Wouldn't it make sense then, to also uso the timeout value given by the '-l' option to the LDAP_OPT_TIMEOUT, or introduce a seperate option if you do not want to mix the different timeout values? I don't see any chance of telling ldapsearch to how to use a timeout value for the LDAP_OPT_TIMEOUT.
Regards
Thomas
Thomas Egerer wrote:
On 06/27/2011 11:58 AM, Howard Chu schrobtete:
Thomas Egerer wrote:
On 06/24/2011 09:15 PM, Howard Chu schrobtete:
You appear to be using a very old version of OpenLDAP then.
This is correct, I am currently using openldap 2.1.30, still...
You're supposed to provide your version info at the *beginning* of the discussion. OpenLDAP 2.1 was obsoleted in 2004.
You're right, my bad. This mail refers to the current git-version of openldap (052ac2f ITS#6828 silence warning in prev commit).
The LDAP_OPT_TIMEOUT setting will timeout any synchronous request, and has done so since early 2007 at least.
... I cannot confirm this. Even when I use openldap 2.4.23 I can reproduce my DoS-scenario by starting a 'nc -l localhost -p 389' and performing an 'ldapsearch -l 5 -h localhost ...' which ends up in an unresponsive ldapsearch.
The "-l" option to ldapsearch sets the Search Request time limit, which is not the same as the API timeout that LDAP_OPT_TIMEOUT controls.
As far as I can read from the default value which is controlled by the LDAP_OPT_TIMEOUT option is -1 which means an infinite waiting time. Wouldn't it make sense then, to also uso the timeout value given by the '-l' option to the LDAP_OPT_TIMEOUT,
No. The -l option tells the server how long to allow a search request to execute once it has started processing. It is specific to search requests only. LDAP_OPT_TIMEOUT affects all LDAP requests made by the client library. The two are completely unrelated. It may be appropriate to set a search time limit of 30 seconds, but on a long search that returns many entries, you would get the first responses much sooner than 30 seconds, so an API timeout of 30 seconds would be ineffective anyway.
or introduce a seperate option
if you do not want to mix the different timeout values? I don't see any chance of telling ldapsearch to how to use a timeout value for the LDAP_OPT_TIMEOUT.
At this point we're no longer in the realm of -devel topics. This is a usage question that belongs on -technical. Read the ldap.conf(5) manpage.
-
Howard Chu -
Thomas Egerer