Viewing Incoming/6912
Full headers

Major security issue: yes  no

Notes:

Notification:

Date: Thu, 21 Apr 2011 10:54:36 +0000
From: daniel@pluta.biz
To: openldap-its@OpenLDAP.org
Subject: authz-regexp DN

Full_Name: authz-regex dnNormalize() filter expression with matching rule
assertion
Version: HEAD
OS: Linux
URL: ftp://ftp.openldap.org/incoming/
Submission from: (NULL) (2001:4ca0:0:fe00:200:5efe:81bb:f4c)


We tried to support/implement case-sensitive logins using SASL DIGEST-MD5.

Imagine the following partial authz-regexp statement:
ldap:///ou=users,ou=eecbcs.de,dc=foo,dc=bar??one?(uid:caseExactMatch:=$1)

During "dnNormalize" the uid is transformed into lowercase which cause the
caseExactMatch to fail:

SASL [conn=1010] Debug: DIGEST-MD5 server step 2
slap_sasl_getdn: u:id converted to uid=user1HAHA,cn=DIGEST-MD5,cn=auth
>>> dnNormalize: <uid=user1HAHA,cn=DIGEST-MD5,cn=auth>
<<< dnNormalize: <uid=user1HAHA,cn=digest-md5,cn=auth>
==>slap_sasl2dn: converting SASL name uid=user1HAHA,cn=digest-md5,cn=auth to
a
DN
==> rewrite_context_apply [depth=1]
string='uid=user1HAHA,cn=digest-md5,cn=auth'
==> rewrite_rule_apply
rule='uid=([^,]+),cn=(PLAIN|LOGIN|OTP|DIGEST-MD5|CRAM-MD5),cn=auth'
string='uid=user1HAHA,cn=digest-md5,cn=auth' [1 pass(es)]
==> rewrite_context_apply [depth=1]
res={0,'ldap:///ou=users,ou=eecbcs.de,dc=foo,dc=bar??one?(uid:caseExactMatch:=user1haha)'}

Followup 1

Date: Sun, 24 Apr 2011 17:35:19 +0200
From: Daniel Pluta <daniel@pluta.biz>
To: openldap-its@OpenLDAP.org
Subject: Re: (ITS#6912) authz-regexp DN normalization of authcIDs

this micro-patch "works for me": 
ftp://ftp.openldap.org/incoming/Daniel-Pluta-110424.patch

Disclaimer: I don't know the details regarding the need for 
normalization but ...
... to my current knowledge and opposed to authDNs, there's no need to 
normalize authcIDs at all?


slapd's behaviour before the patch:

do_bind: dn () SASL mech DIGEST-MD5
SASL [conn=1001] Debug: DIGEST-MD5 server step 2
slap_sasl_getdn: u:id converted to uid=userHAHAHA,cn=DIGEST-MD5,cn=auth
 >>> dnNormalize: <uid=userHAHAHA,cn=DIGEST-MD5,cn=auth>
<<< dnNormalize: <uid=userhahaha,cn=digest-md5,cn=auth>
==>slap_sasl2dn: converting SASL name 
uid=userhahaha,cn=digest-md5,cn=auth to a DN
==> rewrite_context_apply [depth=1] 
string='uid=userhahaha,cn=digest-md5,cn=auth'
==> rewrite_rule_apply 
rule='uid=([^,]+),cn=(PLAIN|LOGIN|OTP|DIGEST-MD5|CRAM-MD5),cn=auth' 
string='uid=userhahaha,cn=digest-md5,cn=auth' [1 pass(es)]
==> rewrite_context_apply [depth=1] 
res={0,'ldap:///ou=users,dc=foo,dc=bar??one?(userLogin=userhahaha)'}
slap_parseURI: parsing 
ldap:///ou=users,dc=foo,dc=bar??one?(userLogin=userhahaha)
ldap_url_parse_ext(ldap:///ou=users,dc=foo,dc=bar??one?(userLogin=userhahaha))
put_filter: "(userLogin=userhahaha)"


slapd's behaviour after the patch has been applied:

do_bind: dn () SASL mech DIGEST-MD5
SASL [conn=1000] Debug: DIGEST-MD5 server step 2
slap_sasl_getdn: u:id converted to uid=userHAHAHA,cn=DIGEST-MD5,cn=auth
==>slap_sasl2dn: converting SASL name 
uid=userHAHAHA,cn=DIGEST-MD5,cn=auth to a DN
==> rewrite_context_apply [depth=1] 
string='uid=userHAHAHA,cn=DIGEST-MD5,cn=auth'
==> rewrite_rule_apply 
rule='uid=([^,]+),cn=(PLAIN|LOGIN|OTP|DIGEST-MD5|CRAM-MD5),cn=auth' 
string='uid=userHAHAHA,cn=DIGEST-MD5,cn=auth' [1 pass(es)]
==> rewrite_context_apply [depth=1] 
res={0,'ldap:///ou=users,dc=foo,dc=bar??one?(userLogin=userHAHAHA)'}
slap_parseURI: parsing 
ldap:///ou=users,dc=foo,dc=bar??one?(userLogin=userHAHAHA)
ldap_url_parse_ext(ldap:///ou=users,dc=foo,dc=bar??one?(userLogin=userHAHAHA))
put_filter: "(userLogin=userHAHAHA)"
put_filter: simple
put_simple_filter: "userLogin=userHAHAHA"

note, the userLogin attribute is defined using octetString-Syntax and 
thus is compared case sensitive

Followup 2

Date: Tue, 03 May 2011 16:10:34 +0200
From: Daniel Pluta <daniel@pluta.biz>
To: openldap-its@OpenLDAP.org
Subject: Re: (ITS#6912) authz-regexp DN normalization of authcIDs

In case authcIDs do not need to be normalized, this seems to be a better 
place to disable normalization:

ftp://ftp.openldap.org/incoming/Daniel-Pluta-110502.patch

Now authzIDs of the form "u:xxxx" are also affected.