Full_Name: John Madden Version: 2.0.14 OS: Solaris 8 URL: ftp://ftp.openldap.org/incoming/ Submission from: (NULL) (168.91.4.66) Using perl's Net::LDAP (for example), it is possible to cause slapd to exit on the assert call in servers/slapd/schema_check.c line 45 -- by sending a NULL value. Example LDIF prior to the modify: dn: uid=jmadden,ou=People,dc=ivy,dc=tec,dc=in,dc=us objectClass: account objectClass: posixAccount objectClass: top objectClass: shadowAccount uid: jmadden cn: jmadden gidNumber: 100 uidNumber: 10042 homeDirectory: /home/jmadden mainframeId: ycn000 loginShell: /bin/bash gecos: John E. Madden,, 921-4691 mailacceptinggeneralid: maildrop: jmadden description: Unix Systems Engineer campus: Central Office Sample perl code to cause the assert() to fail: $result = $ldap->modify( "uid=$uid,ou=People,dc=ivy,dc=tec,dc=in,dc=us", changes => [ replace => [ 'gecos', "$in{'name'},, $in{'phone'}", 'mailacceptinggeneralid', "$in{'alias'}", 'maildrop', "$uid", 'description', "$in{'title'}", 'campus', "$in{'campus'}" ] ] ); Logging: /usr/local/libexec/slapd -d 816 <snip> ber_dump: buf=0x001025d0 ptr=0x00102674 end=0x001026a1 len=45 0000: 30 2b 0a 01 02 30 26 04 0b 64 65 73 63 72 69 70 0+...0&..descrip 0010: 74 69 6f 6e 31 17 04 15 55 6e 69 78 20 53 79 73 tion1...Unix Sys 0020: 74 65 6d 73 20 45 6e 67 69 6e 65 65 72 tems Engineer conn=5 op=1 MOD dn="uid=jmadden,ou=People,dc=ivy,dc=tec,dc=in,dc=us" schema_check.c:45: failed assertion `a->a_vals[0] != NULL' Abort Explanation: in our example, by having $in{'alias'} be NULL, i.e., the user doesn't have a mail alias, slapd fails its assertion and exits. In other words, any user with write permission on a DN can take down slapd. I'd provide an LDIF for the operation itself, but I'm not sure how I'd represent that in LDIF. Please feel free to contact me if more information is necessary.
At 01:26 PM 2001-10-02, jmadden@ivy.tec.in.us wrote: >Full_Name: John Madden >Version: 2.0.14 >OS: Solaris 8 >URL: ftp://ftp.openldap.org/incoming/ >Submission from: (NULL) (168.91.4.66) > > >Using perl's Net::LDAP (for example), it is possible to cause slapd to exit on >the assert call in servers/slapd/schema_check.c line 45 -- by sending a NULL >value. > >Example LDIF prior to the modify: > >dn: uid=jmadden,ou=People,dc=ivy,dc=tec,dc=in,dc=us >objectClass: account >objectClass: posixAccount >objectClass: top >objectClass: shadowAccount >uid: jmadden >cn: jmadden >gidNumber: 100 >uidNumber: 10042 >homeDirectory: /home/jmadden >mainframeId: ycn000 >loginShell: /bin/bash >gecos: John E. Madden,, 921-4691 >mailacceptinggeneralid: >maildrop: jmadden >description: Unix Systems Engineer >campus: Central Office > >Sample perl code to cause the assert() to fail: > >$result = $ldap->modify( > "uid=$uid,ou=People,dc=ivy,dc=tec,dc=in,dc=us", > changes => > [ > replace => [ 'gecos', "$in{'name'},, $in{'phone'}", > 'mailacceptinggeneralid', "$in{'alias'}", > 'maildrop', "$uid", > 'description', "$in{'title'}", > 'campus', "$in{'campus'}" > ] > ] >); I note that net::ldap provides facilities to generate a hex dump of LDAP requests it generates. This can be provided in lieu of the LDIF or ber_dump of the message. >Logging: >/usr/local/libexec/slapd -d 816 No TRACE or ARGS, ugh... (see below). >ber_dump: buf=0x001025d0 ptr=0x00102674 end=0x001026a1 len=45 > 0000: 30 2b 0a 01 02 30 26 04 0b 64 65 73 63 72 69 70 0+...0&..descrip > 0010: 74 69 6f 6e 31 17 04 15 55 6e 69 78 20 53 79 73 tion1...Unix Sys > 0020: 74 65 6d 73 20 45 6e 67 69 6e 65 65 72 tems Engineer This appears to be the BER for the last replace part of the modify request. Above this you should be able to find ber_dump messages containing the most of LDAP message. You should be able to see the characters making up the DN in the right hand column. Normally, you'd just look for the ber_dump just below the TRACE message: do_modify or just above the ARGS message: do_modify: dn (uid=jmadden,ou=People,dc=ivy,dc=tec,dc=in,dc=us) But since you used -d 816, so won't have these. So, you'll have to dig for ber_dump containing the LDAP message. You should be able to page up until you find a ber_dump containing the DN. >conn=5 op=1 MOD dn="uid=jmadden,ou=People,dc=ivy,dc=tec,dc=in,dc=us" >schema_check.c:45: failed assertion `a->a_vals[0] != NULL' >Abort > >Please feel free to contact me if more information is necessary. I think in this case, I'm going to need more complete BER dump to determine exactly what the client request was. Please provide if at all possible.
changed notes
changed notes changed state Open to Release moved from Incoming to Software Bugs
Hello folks, I am running slapd 2.0.18 <<stable>> and when I attempt to run a PHP modify query against the ldap, it crashes the server with an assertion failure on schema check. slapd: schema_check.c:45: entry_schema_check: Assertion `a->a_vals[0] != ((void *)0)' failed. I am making a php-4.0.6 call against the server "ldap_modify". Redhat 7.1; OpenLDAP-2.0.18-stable; php-4.0.6; i686 2x1GHz, dell poweredge 2550, 1Gb ram. >From Debugging: --------------- ldap_read: want=84, got=84 0000: 02 01 03 66 4f 04 32 69 6e 69 74 69 61 6c 73 3d ...fO.2initials= 0010: 61 61 63 2c 6f 75 3d 63 61 6d 70 75 73 6b 65 79 aac,ou=campuskey 0020: 69 6e 64 65 78 2c 64 63 3d 6a 65 66 66 65 72 73 index,dc=jeffers 0030: 6f 6e 2c 64 63 3d 65 64 75 30 19 30 17 0a 01 02 on,dc=edu0.0.... 0040: 30 12 04 0c 74 6a 75 4d 61 78 4b 65 79 56 61 6c 0...tjuMaxKeyVal 0050: 31 02 04 00 1... ber_get_next: tag 0x30 len 84 contents: ber_get_next ldap_read: want=1 error=Resource temporarily unavailable do_modify ber_scanf fmt ({a) ber: ber_get_next on fd 9 failed errno=11 (Resource temporarily unavailable) ber_scanf fmt ({i{a[V]}}) ber: dn2entry_r: dn: "INITIALS=AAC,OU=CAMPUSKEYINDEX,DC=JEFFERSON,DC=EDU" => dn2id( "INITIALS=AAC,OU=CAMPUSKEYINDEX,DC=JEFFERSON,DC=EDU" ) ====> cache_find_entry_dn2id("INITIALS=AAC,OU=CAMPUSKEYINDEX,DC=JEFFERSON,DC=EDU"): 17263 (1 tries) <= dn2id 17263 (in cache) => id2entry_r( 17263 ) ====> cache_find_entry_id( 17263 ) "initials=aac,ou=campuskeyindex,dc=jefferson,dc=edu" (found) (1 tries) <= id2entry_r( 17263 ) 0x818d6f0 (cache) ====> cache_return_entry_r( 17263 ): returned (0) dn2entry_w: dn: "INITIALS=AAC,OU=CAMPUSKEYINDEX,DC=JEFFERSON,DC=EDU" => dn2id( "INITIALS=AAC,OU=CAMPUSKEYINDEX,DC=JEFFERSON,DC=EDU" ) ====> cache_find_entry_dn2id("INITIALS=AAC,OU=CAMPUSKEYINDEX,DC=JEFFERSON,DC=EDU"): 17263 (1 tries) <= dn2id 17263 (in cache) => id2entry_w( 17263 ) ====> cache_find_entry_id( 17263 ) "initials=aac,ou=campuskeyindex,dc=jefferson,dc=edu" (found) (1 tries) <= id2entry_w( 17263 ) 0x818d6f0 (cache) ldbm_modify_internal: INITIALS=AAC,OU=CAMPUSKEYINDEX,DC=JEFFERSON,DC=EDU <= acl_access_allowed: granted to database root slapd: schema_check.c:45: entry_schema_check: Assertion `a->a_vals[0] != ((void *)0)' failed. Best Regards, E. M. Recio ******************************************************** * Chief Systems Engineer, Behavioral Informatics Inc. * * EMAIL: n2wog@usa.net | AIM: emrecio * * PAGER: (215) 314-2622 | FAX: (215) 503-2648 * * CELL: (215) 681-5612 | WORK: (215) 503-0986 * ******************************************************** ____________________________________________________________________ Get free e-mail and a permanent address at http://www.amexmail.com/?A=1
A fix for this problem has been made to both the HEAD and OPENLDAP_REL_ENG_2 branches, please test. The following URL provides the a patch against 2.0.18. http://www.openldap.org/devel/cvsweb.cgi/servers/slapd/value.c.diff?r1=1.8.8.5&r2=1.8.8.6 The bug can be induced in previous versions by issuing the following LDAP operation (described using LDIFv1): dn: cn=any Entry within the naming context changetype: modify replace: userPassword userPassword: - Kurt
changed notes changed state Release to Closed
moved from Software Bugs to Archive.Software Bugs
Fixed in HEAD Fixed in RE20