OpenLDAP
Up to top level
Build   Contrib   Development   Documentation   Historical   Incoming   Software Bugs   Software Enhancements   Web  

Logged in as guest

Viewing Incoming/6463
Full headers

From: jochen@keutel.de
Subject: dnssrv_back_referrals: ldaps not handled, search base gone
Compose comment
Download message
State:
0 replies:
1 followups: 1

Major security issue: yes  no

Notes:

Notification:


Date: Wed, 27 Jan 2010 01:41:54 +0000
From: jochen@keutel.de
To: openldap-its@OpenLDAP.org
Subject: dnssrv_back_referrals: ldaps not handled, search base gone
Full_Name: Jochen Keutel
Version: 2.4.21
OS: Solaris 10
URL: ftp://ftp.openldap.org/incoming/
Submission from: (NULL) (87.159.206.14)


dnssrv_back_referrals() always returns ldap URLs - even when the original
request was a ldaps query.

Additionally only protocol and hostname are put into the URL - the search base
doesn't appear any more.

Problematic code:

		url.bv_len = STRLENOF( "ldap://" ) + strlen( hosts[i] );
		url.bv_val = ch_malloc( url.bv_len + 1 );

		strcpy( url.bv_val, "ldap://" );
		strcpy( &url.bv_val[STRLENOF( "ldap://" )], hosts[i] );

I'm not sure whether you want me to deliver a complete patch or not ... 

Thanks to my colleague Manuel Gaupp for detecting this problem.

Best regards,  Jochen.

Followup 1

Download message
Date: Sun, 18 Apr 2010 00:52:42 +0200 (CEST)
Subject: Re: (ITS#6463) dnssrv_back_referrals: ldaps not handled,
      search base gone
From: masarati@aero.polimi.it
To: jochen@keutel.de
Cc: openldap-its@openldap.org
> Full_Name: Jochen Keutel
> Version: 2.4.21
> OS: Solaris 10
> URL: ftp://ftp.openldap.org/incoming/
> Submission from: (NULL) (87.159.206.14)
>
>
> dnssrv_back_referrals() always returns ldap URLs - even when the original
> request was a ldaps query.

This is a (logical) duplicate of ITS#6462; see related answers.

> Additionally only protocol and hostname are put into the URL - the search
> base
> doesn't appear any more.
>
> Problematic code:
>
> 		url.bv_len = STRLENOF( "ldap://" ) + strlen( hosts[i] );
> 		url.bv_val = ch_malloc( url.bv_len + 1 );
>
> 		strcpy( url.bv_val, "ldap://" );
> 		strcpy( &url.bv_val[STRLENOF( "ldap://" )], hosts[i] );
>
> I'm not sure whether you want me to deliver a complete patch or not ...

This behavior conforms to RFC4511, section 4.1.10:

   - If the <dn> part is present, the client uses this name in its next
     request to progress the operation, and if it is not present the
     client uses the same name as in the original request.

I note that few lines above the same RFC states:

   - It is RECOMMENDED that the <dn> part be present to avoid ambiguity.

However, slapd-dnssrv(5) computes the referral from DNS SRV records,
rather than returning data it knows about.  So returning the <dn> part
here would be incorrect, in my opinion, as the client could legitimately
rely on the fact that the returned DN is appropriate, while it may not.

p.


Up to top level
Build   Contrib   Development   Documentation   Historical   Incoming   Software Bugs   Software Enhancements   Web  

Logged in as guest


The OpenLDAP Issue Tracking System uses a hacked version of JitterBug

______________
© Copyright 2013, OpenLDAP Foundation, info@OpenLDAP.org