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

Logged in as guest

Viewing Development/6475
Full headers

From: manu@netbsd.org
Subject: SASL OTP and syncrepl
Compose comment
Download message
State:
0 replies:
10 followups: 1 2 3 4 5 6 7 8 9 10

Major security issue: yes  no

Notes:

Notification:


Date: Wed, 17 Feb 2010 03:24:04 +0000
From: manu@netbsd.org
To: openldap-its@OpenLDAP.org
Subject: SASL OTP and syncrepl
Full_Name: Emmanuel Dreyfus
Version: any
OS: any
URL: ftp://ftp.openldap.org/incoming/ldapotp.tgz
Submission from: (NULL) (213.41.141.172)


When binding using SASL OTP to a replica, the bind works, but the
cmusaslsecretOTP attribute is modified on the replica and fail to be propagated
to the master. On the next modification, the master will overwrite the replica's
updated cmusaslsecretOTP value.

Here is a script that exhibit the behaviour:
ftp://ftp.openldap.org/incoming/ldapotp.tgz

That require SASL enabled OpenLDAP, with the OTP plugin installed. The PATH in
run.sh must probably be adjusted.

Followup 1

Download message
Date: Sun, 21 Feb 2010 14:00:35 +0100 (CET)
Subject: ITS#6475
From: masarati@aero.polimi.it
To: openldap-its@openldap.org
Cc: "Emmanuel Dreyfus" <manu@netbsd.org>
The "easy" fix is here

<ftp://ftp.openldap.org/incoming/pierangelo-masarati-2010-02-21-dontusecopy-otp.patch>

I haven't committed it (needs some polishing) because it touches
slapo-chain(5) in a couple of places, and I'd rather be sure it does not
break anything.  I won't be able to work at it for a while.  It needs some
polishing (SASL attributes that may need dontUseCopy should be at least
configurable and so).

Please test.



Followup 2

Download message
Date: Wed, 24 Feb 2010 21:30:24 +0100 (CET)
Subject: Re: ITS#6475
From: masarati@aero.polimi.it
To: openldap-its@openldap.org
Cc: manu@netbsd.org
A more complete fix is here:

<ftp://ftp.openldap.org/incoming/pierangelo-masarati-2010-02-24-dontusecopy-otp.patch>

It allows to configure what SASL auxprop names need the "dontUseCopy"
approach.  The "cmusaslsecretOTP" is set by default, if known through the
schema.

Please test.  p.



Followup 3

Download message
To: masarati@aero.polimi.it, openldap-its@openldap.org
Subject: Re: ITS#6475
From: manu@netbsd.org (Emmanuel Dreyfus)
Date: Thu, 25 Feb 2010 05:34:47 +0100
<masarati@aero.polimi.it> wrote:

> It allows to configure what SASL auxprop names need the "dontUseCopy"
> approach.  The "cmusaslsecretOTP" is set by default, if known through the
> schema.

Seems nice. I hope I'll have time to test this week.

-- 
Emmanuel Dreyfus
http://hcpnet.free.fr/pubz
manu@netbsd.org



Followup 4

Download message
To: masarati@aero.polimi.it
Cc: openldap-its@openldap.org
Subject: Re: ITS#6475
From: manu@netbsd.org (Emmanuel Dreyfus)
Date: Sun, 14 Mar 2010 14:29:23 +0100
<masarati@aero.polimi.it> wrote:

> Please test.  p.

It works, but needs to adjustement to the master ACL. My basic
configuration yield me this at OTP bind on replica:
ldap_sasl_interactive_bind_s: Bad parameter to an ldap routine (-9)

replica slapd  logs:

conn=1001 op=0 RESULT tag=103 err=50 text=
SASL [conn=1001] Failure: Error putting OTP secret
send_ldap_result: conn=1001 op=0 p=3
send_ldap_result: err=80 matched="" text="SASL(-1): generic failure:
Error putting OTP secret"

This has been fixed on the master, by adding this at the beginning of
the ACL:

access to * attrs=cmusaslsecretOTP
    by dn.regex="cn=replica,o=test" write stop
    by * break


Another point: bind on the replica is impossible when the master is
down. I understand this is to prevent replaying the same OTP on multiple
replicas, but that defeats the purpose of setting up replicas for fail
over. What about making the behavior configurable?

-- 
Emmanuel Dreyfus
http://hcpnet.free.fr/pubz
manu@netbsd.org



Followup 5

Download message
Date: Mon, 15 Mar 2010 07:35:38 +0100 (CET)
Subject: Re: ITS#6475
From: masarati@aero.polimi.it
To: manu@netbsd.org
Cc: openldap-its@openldap.org
> <masarati@aero.polimi.it> wrote:
>
>> Please test.  p.
>
> It works, but needs to adjustement to the master ACL. My basic
> configuration yield me this at OTP bind on replica:
> ldap_sasl_interactive_bind_s: Bad parameter to an ldap routine (-9)
>
> replica slapd  logs:
>
> conn=1001 op=0 RESULT tag=103 err=50 text=
> SASL [conn=1001] Failure: Error putting OTP secret
> send_ldap_result: conn=1001 op=0 p=3
> send_ldap_result: err=80 matched="" text="SASL(-1): generic failure:
> Error putting OTP secret"
>
> This has been fixed on the master, by adding this at the beginning of
> the ACL:
>
> access to * attrs=cmusaslsecretOTP
>     by dn.regex="cn=replica,o=test" write stop
>     by * break

This is orthogonal to the sasl auxprops discussion.  It's a matter of
well-configuring the authorizing identity in slapo-chain(5).

> Another point: bind on the replica is impossible when the master is
> down. I understand this is to prevent replaying the same OTP on multiple
> replicas, but that defeats the purpose of setting up replicas for fail
> over.

This was clearly pointed out at the beginning of the discussion.  You
can't have both, it should be clear.

> What about making the behavior configurable?

Right now, cmusaslsecretOTP is hardcoded, because if the shadow copy is
used, OTP breaks.  If it is acceptable to have it broken, we can remove
the hardcoding, and let admins decide whether they prefer fail-over over
consistency.  I'd have no doubt, and favor consistency.

p.



Followup 6

Download message
To: masarati@aero.polimi.it
Cc: openldap-its@openldap.org
Subject: Re: ITS#6475
From: manu@netbsd.org (Emmanuel Dreyfus)
Date: Mon, 15 Mar 2010 07:48:03 +0100
<masarati@aero.polimi.it> wrote:

> > access to * attrs=cmusaslsecretOTP
> >     by dn.regex="cn=replica,o=test" write stop
> >     by * break
> 
> This is orthogonal to the sasl auxprops discussion.  It's a matter of
> well-configuring the authorizing identity in slapo-chain(5).

I pointed it here for future reference because this is an unusual case.
I suspect everyone configure replicas with universal read-only access.
For this to work, replica must also have write access to
cmusaslsecretOTP. 
 
> > Another point: bind on the replica is impossible when the master is
> > down. I understand this is to prevent replaying the same OTP on
multiple
> > replicas, but that defeats the purpose of setting up replicas for fail
> > over.
> 
> This was clearly pointed out at the beginning of the discussion.  You
> can't have both, it should be clear.

Yes, I understand that.

> Right now, cmusaslsecretOTP is hardcoded, because if the shadow copy is
> used, OTP breaks.  If it is acceptable to have it broken, we can remove
> the hardcoding, and let admins decide whether they prefer fail-over over
> consistency.  I'd have no doubt, and favor consistency.

When you tell about using the shadow copy, the modification will still
be sent to the master, right? Such a behavior allows replays attacks
within the modification propagation time frame, but it ensures that bind
are still possible when then master is down. I think it could be
interesting to have a configuration setting for that.

-- 
Emmanuel Dreyfus
http://hcpnet.free.fr/pubz
manu@netbsd.org



Followup 7

Download message
Date: Mon, 15 Mar 2010 07:57:26 +0100 (CET)
Subject: Re: ITS#6475
From: masarati@aero.polimi.it
To: "Emmanuel Dreyfus" <manu@netbsd.org>
Cc: openldap-its@openldap.org
> <masarati@aero.polimi.it> wrote:
>
>> > access to * attrs=cmusaslsecretOTP
>> >     by dn.regex="cn=replica,o=test" write stop
>> >     by * break
>>
>> This is orthogonal to the sasl auxprops discussion.  It's a matter of
>> well-configuring the authorizing identity in slapo-chain(5).
>
> I pointed it here for future reference because this is an unusual case.
> I suspect everyone configure replicas with universal read-only access.
> For this to work, replica must also have write access to
> cmusaslsecretOTP.

Well, if a shadow uses slapo-chain(5), the producer must be configured in
order to allow writes coming from the shadow.

>> > Another point: bind on the replica is impossible when the master
is
>> > down. I understand this is to prevent replaying the same OTP on
>> multiple
>> > replicas, but that defeats the purpose of setting up replicas for
fail
>> > over.
>>
>> This was clearly pointed out at the beginning of the discussion.  You
>> can't have both, it should be clear.
>
> Yes, I understand that.
>
>> Right now, cmusaslsecretOTP is hardcoded, because if the shadow copy is
>> used, OTP breaks.  If it is acceptable to have it broken, we can remove
>> the hardcoding, and let admins decide whether they prefer fail-over
over
>> consistency.  I'd have no doubt, and favor consistency.
>
> When you tell about using the shadow copy, the modification will still
> be sent to the master, right?

Not in the original code.  In that case, the modification was bypassing
replication, thus it was being applied to the shadow without generating a
referral.  The alternative, inconsistent solution you seem to indicate
would require to replay the modification as internal in case the
modification to the producer failed because the service was not available.

> Such a behavior allows replays attacks
> within the modification propagation time frame, but it ensures that bind
> are still possible when then master is down. I think it could be
> interesting to have a configuration setting for that.

We should bring this to -devel, to see whether it makes sense and whether
it would be acceptable.

p.



Followup 8

Download message
Date: Thu, 15 Apr 2010 18:20:01 +0200 (CEST)
Subject: Re: ITS#6475
From: masarati@aero.polimi.it
To: manu@netbsd.org
Cc: openldap-its@openldap.org
>> Such a behavior allows replays attacks
>> within the modification propagation time frame, but it ensures that
bind
>> are still possible when then master is down. I think it could be
>> interesting to have a configuration setting for that.
>
> We should bring this to -devel, to see whether it makes sense and whether
> it would be acceptable.

A fix in this sense is in HEAD.  Modifications consist in the original
patch (well-known SASL mechs exploit the dontUseCopy control to actually
lookup and propagate auxprops to the master ("sasl-auxprops-dontusecopy"
directive).  Another directive ("sasl-auxprops-dontusecopy-ignore") allows
to ignore errors and lookup/store auxprops locally.  By default it's FALSE
for consistency.  If set to TRUE, replicas will be misaligned, but service
will be possible.  Choose what best fits your needs.  Both directives are
not documented yet, as I consider the whole code highly experimental. 
Right now, is only built when #define LDAP_DEVEL.

Please note that the relatively minor modifications to slapo-chain(5) are
not conditioned on #define SLAP_AUXPROP_DONTUSECOPY, because I think they
are generally useful, and I've checked they don't break anything (I could
check so far).  Please report any inconvenience.

p.



Followup 9

Download message
Date: Mon, 19 Jul 2010 22:17:15 +0200
From: Daniel Pluta <daniel@pluta.biz>
To: openldap-its@OpenLDAP.org
CC: masarati@aero.polimi.it, manu@netbsd.org
Subject: Re: (ITS#6475) SASL OTP and syncrepl
Hi,

I've received segmentation faults during some basic SASL OTP testing 
using CVS HEAD.

Below you'll find a small patch (against HEAD) which seems to fix this 
issue ...

Before the patch:
root@tingletangle:~/repos/openldap# /usr/local/openldap/bin/ldapsearch 
-v -Y OTP -U test1
ldap_initialize( <DEFAULT> )
SASL/OTP authentication started
ldap_sasl_interactive_bind_s: Can't contact LDAP server (-1) (<== slapd 
segfault)

After the patch has been applied:
root@tingletangle:~/repos/openldap# /usr/local/openldap/bin/ldapsearch 
-v -Y OTP -U test1
ldap_initialize( <DEFAULT> )
SASL/OTP authentication started
Challenge: otp-md5 498 ti6311 ext
Please enter your one-time password:  huhu
ldap_sasl_interactive_bind_s: Invalid credentials (49)
        additional info: SASL(-13): authentication failure: (<== slapd 
still running ;-) )

As I'm not (yet ;-)) an OTP-expert I have not tested any further because 
I currently just don't know how to calculate the one-time password based 
on the challenge ...

Best regards,
Daniel



Index: servers/slapd/sasl.c
===================================================================
RCS file: /repo/OpenLDAP/pkg/ldap/servers/slapd/sasl.c,v
retrieving revision 1.274
diff -u -r1.274 sasl.c
--- servers/slapd/sasl.c        15 Apr 2010 16:13:54 -0000      1.274
+++ servers/slapd/sasl.c        19 Jul 2010 19:55:11 -0000
@@ -548,7 +548,7 @@
                                        op.o_req_ndn.bv_val = (char 
*)pr[i].values[0];
                        }
 #ifdef SLAP_AUXPROP_DONTUSECOPY
-                       {
+                       if ( slap_dontUseCopy_propnames != NULL ) {
                                struct berval bv;
                                ber_str2bv( &pr[i].name[1], 0, 1, &bv );
                                for ( j = 0; !BER_BVISNULL( 
&slap_dontUseCopy_propnames[ j ] ); j++ ) {



Followup 10

Download message
To: openldap-its@OpenLDAP.org
Cc: masarati@aero.polimi.it
Subject: Re: (ITS#6475) SASL OTP and syncrepl
From: manu@netbsd.org (Emmanuel Dreyfus)
Date: Tue, 20 Jul 2010 04:21:52 +0200
Daniel Pluta <daniel@pluta.biz> wrote:

> As I'm not (yet ;-)) an OTP-expert I have not tested any further because
> I currently just don't know how to calculate the one-time password based
> on the challenge ...

skey(1) can do it for you.

-- 
Emmanuel Dreyfus
http://hcpnet.free.fr/pubz
manu@netbsd.org


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