Re: unauthorized entity may delete attributes (ITS#1530)

[Kurt@OpenLDAP.org]

A fix for this issue has been released in 2.0.20!
        Kurt

At 08:09 AM 2002-01-14, Thomas.Fritz@bam.de wrote:
>Full_Name: Thomas Fritz
>Version: 2.0.19
>OS: Linux
>URL: ftp://ftp.openldap.org/incoming/
>Submission from: (NULL) (141.63.61.40)
>
>
>slapd 2.0.x, allows unauthorized entities to replace the values
>of arbitrary attributes by an empty set of values, thus deleting
>the attribute completely.
>(This is true, if schema checking does not force the 
>existence of the attribute)
>
>To demonstrate the problem for an environment, where anonymous 
>bind is not disabled, prepare a file 'rm-attr.ldif', with e.g.
>the following contents:
>
>   dn: uid=some-mail-user,ou=people,dc=foo,dc=bar
>   replace: mail
>
>Running
>
>   ldapmodify -x -f rm-attr.ldif
>
>(assuming that URI and BASE are set in ldap.conf)
>
>will delete all mail adresses of 'some-mail-user'.
>
>This works even if you lock down access to  
>
>   access to * by * none
>
>To reproduce the bug for authenticated bind, e.g. if you have
>disabled acceptance of anonymous bind requests, you need at 
>least
>
>   access to attr=userPassword by anonymous auth
>
>and run ldapmodify binding as any user.
>
>
>This misbehaviour is due to the implementation of acls in 
>servers/slapd/acl.c, where REPLACE requests are handled the same
>way as ADD requests. REPLACE requests, however, delete all values 
>of the attribute in a first step, and replace by 'nothing' in 
>LDAP v3 means deleting the attribute itself. 
>Hence, an entity requesting REPLACE should need permission for
>the current values to be deleted, and, like ADD requests, 
>permission to add its set of new values to the attribute.
>
>When using LDAP v2 with slapd 2.0.x, i.e. ldapmodify -P 2, 
>slapd behaves as with LDAP v3 and has the same problem.
>In LDAP v2 the behaviour for empty REPLACE lists is not defined
>and slapd 1.x generates an error:
>
>   ldap_modify: Protocol error
>           additional info: no values given
>
>
>If somebody needs a quick patch, I suggest, that for REPLACE 
>requests, the requesting entity should be checked for write 
>access to the attribute itself, i.e. no matter what value:
>
>acl.c
>...
>   case LDAP_MOD_REPLACE:
>           /* patch begin ***/
>           if ( ! access_allowed( be, conn, op, e, 
>                                  mlist->sml_desc, 
>                                  NULL, ACL_WRITE ) ) {
>                   return( 0 );
>           }
>           break;
>           /*** patch end */
>
>   case LDAP_MOD_ADD:
>...