openldap-bugs

openldap-bugs@openldap.org

1 participants
21065 discussions

(ITS#7851) [PATCH] buffer overrun in password checkers with malformed hash
by ryan＠nardis.ca 11 May '14

11 May '14

Full_Name: Ryan Tandy Version: master, commit 141f1680 OS: Ubuntu 14.04 URL: ftp://ftp.openldap.org/incoming/rtandy_20140511_fix-passwd-b64-buffer.patch Submission from: (NULL) (24.68.121.206) The password checkers call lutil_b64_pton like this: rc = lutil_b64_pton(passwd->bv_val, orig_pass, passwd->bv_len); However, the size of orig_pass is actually only 3/4 of passwd->bv_len. Normally this isn't a problem; however, if the length of the password hash is not a multiple of 4, then LUTIL_BASE64_DECODE_LEN rounds down, orig_pass gets a shorter buffer allocated than is actually needed, and it's possible for lutil_b64_pton to write past its end. (How can that happen? An admin could mess up copy-pasting from slappasswd to userPassword/olcRootPW, as could a user with write access to their own userPassword who decided to set it manually.) Example: $ slappasswd -s secret -h '{SSHA}' {SSHA}86ks4vJqfruLKer9skuEpTmgPxcaqSLe If we lose the last character ('e') and try to authenticate against the length 31 string, clang's AddressSanitizer notices: ==15335==ERROR: AddressSanitizer: heap-buffer-overflow on address 0x603000049736 at pc 0xef0720 bp 0x7fa9b38d1c10 sp 0x7fa9b38d1c08 WRITE of size 1 at 0x603000049736 thread T2 #0 0xef071f in lutil_b64_pton (libraries/liblutil/base64.c:225) #1 0xe9547c in chk_ssha1 (libraries/liblutil/passwd.c:508) #2 0xe90a09 in lutil_passwd (libraries/liblutil/passwd.c:327) #3 0x7d5e1c in slap_passwd_check (servers/slapd/passwd.c:529) [snip ...] 0x603000049736 is located 0 bytes to the right of 22-byte region [0x603000049720,0x603000049736) allocated by thread T2 here: #0 0x43c9a4 in malloc (/opt/openldap/libexec/slapd+0x43c9a4) #1 0x112903f in ber_memalloc_x (libraries/liblber/memory.c:228) #2 0x1129396 in ber_memalloc (libraries/liblber/memory.c:244) #3 0xe952ea in chk_ssha1 (libraries/liblutil/passwd.c:503) #4 0xe90a09 in lutil_passwd (libraries/liblutil/passwd.c:327) #5 0x7d5e1c in slap_passwd_check (servers/slapd/passwd.c:529) [snip...] (Built with ./configure CC=clang CFLAGS="-O0 -g -fsanitize=address") Patch in URL. (Apparently the apr1 passwd module has CRLF endings; sorry for the noisy diff.) BTW, I noticed in the same routines that orig_pass is allocated with + 1 to the required length, as if it were to be null-terminated, but that's never done. Is that intentional? (AFAICS ber_memalloc doesn't zero memory, maybe I'm wrong.) thanks, Ryan

1 0

Re: (ITS#7850) slapd crashes on modrdn to an attr with no equality matching rule
by ryan＠nardis.ca 09 May '14

09 May '14

On Fri, May 9, 2014 at 11:33 AM, Howard Chu <hyc(a)symas.com> wrote: > Thanks for the report. Should be fixed now in git master, please test. $ ldapmodrdn -x -D cn=root,dc=example,dc=com -W 'cn=Ryan Tandy,dc=example,dc=com' 'jpegPhoto=test' Enter LDAP Password: Rename Result: Naming violation (64) Additional info: naming attribute has no equality matching rule Confirmed fixed.

1 0

Re: (ITS#7850) slapd crashes on modrdn to an attr with no equality matching rule
by hyc＠symas.com 09 May '14

09 May '14

ryan(a)nardis.ca wrote: > Full_Name: Ryan Tandy > Version: HEAD > OS: Ubuntu 14.04 > URL: > Submission from: (NULL) (142.32.208.226) > > > Debian bug report: http://bugs.debian.org/666515 > > Confirmed on master (at commit fcdd3a06) and RE24 (at commit 1253d7c1). Thanks for the report. Should be fixed now in git master, please test. > > ldapadd or slapadd of an entry with a naming attribute such as 'audio' or > 'jpegPhoto' is rejected with a reasonable error message: > > $ slapadd > dn: jpegPhoto=test,dc=example,dc=com > objectClass: inetOrgPerson > > slapadd: dn="jpegPhoto=test,dc=example,dc=com" (line=1): (64) naming attribute > 'jpegPhoto' has no equality matching rule > > However, creating an entry with a valid DN and using ldapmodrdn to request a > change of the naming attr to 'jpegPhoto' crashes slapd: > > $ slapadd > dn: cn=Ryan Tandy,dc=example,dc=com > objectClass: inetOrgPerson > sn: Tandy > jpegPhoto: test > > $ [start slapd...] > $ ldapmodrdn -x -D cn=root,dc=example,dc=com -W 'cn=Ryan > Tandy,dc=example,dc=com' 'jpegPhoto=test' > Enter LDAP Password: > ldap_result: Can't contact LDAP server (-1) > > Program received signal SIGSEGV, Segmentation fault. > [Switching to Thread 0x7ffd81a60700 (LWP 9095)] > 0x00000000004667f3 in slap_modrdn2mods (op=0x7ffd740026b0, rs=0x7ffd81a5faf0) at > modrdn.c:448 > 448 if( desc->ad_type->sat_equality->smr_normalize) { > (gdb) bt full > #0 0x00000000004667f3 in slap_modrdn2mods (op=0x7ffd740026b0, > rs=0x7ffd81a5faf0) at modrdn.c:448 > desc = 0x9add80 > mod_tmp = 0x7ffd74002670 > a_cnt = 0 > d_cnt = 32765 > old_rdn = 0x0 > new_rdn = 0x7ffd74003090 > __PRETTY_FUNCTION__ = "slap_modrdn2mods" > #1 0x0000000000465688 in do_modrdn (op=0x7ffd740026b0, rs=0x7ffd81a5faf0) at > modrdn.c:179 > dn = {bv_len = 31, bv_val = 0x7ffd74102c77 "cn=Ryan > Tandy,dc=example,dc=com"} > newrdn = {bv_len = 14, bv_val = 0x7ffd74102c98 "jpegPhoto=test"} > newSuperior = {bv_len = 0, bv_val = 0x0} > deloldrdn = 0 > pnewSuperior = {bv_len = 0, bv_val = 0x0} > nnewSuperior = {bv_len = 0, bv_val = 0x0} > length = 0 > #2 0x000000000044029f in connection_operation (ctx=0x7ffd81a5fc40, > arg_v=0x7ffd740026b0) at connection.c:1134 > rc = 80 > cancel = 0 > op = 0x7ffd740026b0 > rs = {sr_type = REP_RESULT, sr_tag = 0, sr_msgid = 0, sr_err = 0, > sr_matched = 0x0, sr_text = 0x0, sr_ref = 0x0, > sr_ctrls = 0x0, sr_un = {sru_search = {r_entry = 0x0, r_attr_flags = > 0, r_operational_attrs = 0x0, r_attrs = 0x0, > r_nentries = 0, r_v2ref = 0x0}, sru_sasl = {r_sasldata = 0x0}, > sru_extended = {r_rspoid = 0x0, r_rspdata = 0x0}}, > sr_flags = 0} > tag = 108 > opidx = SLAP_OP_MODRDN > conn = 0x7ffff7e6ae90 > memctx = 0x7ffd74002bf0 > memctx_null = 0x0 > memsiz = 1048576 > __PRETTY_FUNCTION__ = "connection_operation" > #3 0x00000000004408f8 in connection_read_thread (ctx=0x7ffd81a5fc40, argv=0x10) > at connection.c:1270 > rc = 0 > cri = {op = 0x7ffd740026b0, func = 0x0, arg = 0x0, ctx = 0x7ffd81a5fc40, > nullop = 0} > s = 16 > #4 0x00007ffff7b89e5e in ldap_int_thread_pool_wrapper (xpool=0x7fa480) at > tpool.c:945 > pq = 0x7fa480 > pool = 0x7fa370 > task = 0x7ffd7c0008c0 > work_list = 0x7fa4f0 > ctx = {ltu_pq = 0x7fa480, ltu_id = 140726778595072, ltu_key = {{ltk_key > = 0x43fd34 <conn_counter_init>, > ltk_data = 0x7ffd74002ae0, ltk_free = 0x43fb86 > <conn_counter_destroy>}, {ltk_key = 0x4b9a08 <slap_sl_mem_init>, > ltk_data = 0x7ffd74002bf0, ltk_free = 0x4b982d > <slap_sl_mem_destroy>}, {ltk_key = 0x45c06b <slap_op_free>, > ltk_data = 0x0, ltk_free = 0x45bfbe <slap_op_q_destroy>}, {ltk_key > = 0x0, ltk_data = 0x0, > ltk_free = 0x0} <repeats 23 times>, {ltk_key = 0x0, ltk_data = > 0xe81b289de6cb1252, ltk_free = 0x80}, {ltk_key = 0x0, > ltk_data = 0x0, ltk_free = 0x0}, {ltk_key = 0x0, ltk_data = 0x0, > ltk_free = 0x0}, {ltk_key = 0x0, ltk_data = 0x0, > ltk_free = 0x0}, {ltk_key = 0x0, ltk_data = 0x0, ltk_free = 0x0}, > {ltk_key = 0x0, ltk_data = 0x0, ltk_free = 0x0}}} > kctx = 0x0 > i = 32 > keyslot = 586 > hash = 2858034762 > pool_lock = 0 > freeme = 0 > __PRETTY_FUNCTION__ = "ldap_int_thread_pool_wrapper" > #5 0x00007ffff5dbf062 in start_thread (arg=0x7ffd81a60700) at > pthread_create.c:312 > __res = <optimized out> > pd = 0x7ffd81a60700 > now = <optimized out> > unwind_buf = {cancel_jmp_buf = {{jmp_buf = {140726778595072, > 1720423256181903954, 1, 140737354125408, 0, 140726778595072, > -1721737773892038062, -1720445005621816750}, mask_was_saved = > 0}}, priv = {pad = {0x0, 0x0, 0x0, 0x0}, data = { > prev = 0x0, cleanup = 0x0, canceltype = 0}}} > not_first_call = <optimized out> > pagesize_m1 = <optimized out> > sp = <optimized out> > freesize = <optimized out> > __PRETTY_FUNCTION__ = "start_thread" > #6 0x00007ffff5af2bfd in clone () at > ../sysdeps/unix/sysv/linux/x86_64/clone.S:111 > No locals. > > The problem is a dereference of the missing equality rule: > > (gdb) p desc->ad_type > $1 = (AttributeType *) 0x83ec70 > (gdb) p desc->ad_type->sat_equality > $2 = (MatchingRule *) 0x0 > > -- -- Howard Chu CTO, Symas Corp. http://www.symas.com Director, Highland Sun http://highlandsun.com/hyc/ Chief Architect, OpenLDAP http://www.openldap.org/project/

1 0

Re: (ITS#6890) SHA2 Password Hashing not working
by ryan＠nardis.ca 09 May '14

09 May '14

Hi, This is fixed by ITS#7284, included since 2.4.32. slappasswd -o module-load=pw-sha2 -h '{SHA512}' thanks, Ryan

1 0

Re: (ITS#6939) slapd double free corruption with olcTlsCipherSuite and GnuTLS
by quanah＠zimbra.com 08 May '14

08 May '14

Thanks, marked duplicate and closed. --Quanah --On May 8, 2014 at 9:42:07 PM +0000 ryan(a)nardis.ca wrote: > I think this might be a duplicate of ITS#7500. > > -- Quanah Gibson-Mount Server Architect Zimbra, Inc -------------------- Zimbra :: the leader in open source messaging and collaboration

1 0

(ITS#6939) slapd double free corruption with olcTlsCipherSuite and GnuTLS
by ryan＠nardis.ca 08 May '14

08 May '14

I think this might be a duplicate of ITS#7500.

1 0

(ITS#7850) slapd crashes on modrdn to an attr with no equality matching rule
by ryan＠nardis.ca 08 May '14

08 May '14

Full_Name: Ryan Tandy Version: HEAD OS: Ubuntu 14.04 URL: Submission from: (NULL) (142.32.208.226) Debian bug report: http://bugs.debian.org/666515 Confirmed on master (at commit fcdd3a06) and RE24 (at commit 1253d7c1). ldapadd or slapadd of an entry with a naming attribute such as 'audio' or 'jpegPhoto' is rejected with a reasonable error message: $ slapadd dn: jpegPhoto=test,dc=example,dc=com objectClass: inetOrgPerson slapadd: dn="jpegPhoto=test,dc=example,dc=com" (line=1): (64) naming attribute 'jpegPhoto' has no equality matching rule However, creating an entry with a valid DN and using ldapmodrdn to request a change of the naming attr to 'jpegPhoto' crashes slapd: $ slapadd dn: cn=Ryan Tandy,dc=example,dc=com objectClass: inetOrgPerson sn: Tandy jpegPhoto: test $ [start slapd...] $ ldapmodrdn -x -D cn=root,dc=example,dc=com -W 'cn=Ryan Tandy,dc=example,dc=com' 'jpegPhoto=test' Enter LDAP Password: ldap_result: Can't contact LDAP server (-1) Program received signal SIGSEGV, Segmentation fault. [Switching to Thread 0x7ffd81a60700 (LWP 9095)] 0x00000000004667f3 in slap_modrdn2mods (op=0x7ffd740026b0, rs=0x7ffd81a5faf0) at modrdn.c:448 448 if( desc->ad_type->sat_equality->smr_normalize) { (gdb) bt full #0 0x00000000004667f3 in slap_modrdn2mods (op=0x7ffd740026b0, rs=0x7ffd81a5faf0) at modrdn.c:448 desc = 0x9add80 mod_tmp = 0x7ffd74002670 a_cnt = 0 d_cnt = 32765 old_rdn = 0x0 new_rdn = 0x7ffd74003090 __PRETTY_FUNCTION__ = "slap_modrdn2mods" #1 0x0000000000465688 in do_modrdn (op=0x7ffd740026b0, rs=0x7ffd81a5faf0) at modrdn.c:179 dn = {bv_len = 31, bv_val = 0x7ffd74102c77 "cn=Ryan Tandy,dc=example,dc=com"} newrdn = {bv_len = 14, bv_val = 0x7ffd74102c98 "jpegPhoto=test"} newSuperior = {bv_len = 0, bv_val = 0x0} deloldrdn = 0 pnewSuperior = {bv_len = 0, bv_val = 0x0} nnewSuperior = {bv_len = 0, bv_val = 0x0} length = 0 #2 0x000000000044029f in connection_operation (ctx=0x7ffd81a5fc40, arg_v=0x7ffd740026b0) at connection.c:1134 rc = 80 cancel = 0 op = 0x7ffd740026b0 rs = {sr_type = REP_RESULT, sr_tag = 0, sr_msgid = 0, sr_err = 0, sr_matched = 0x0, sr_text = 0x0, sr_ref = 0x0, sr_ctrls = 0x0, sr_un = {sru_search = {r_entry = 0x0, r_attr_flags = 0, r_operational_attrs = 0x0, r_attrs = 0x0, r_nentries = 0, r_v2ref = 0x0}, sru_sasl = {r_sasldata = 0x0}, sru_extended = {r_rspoid = 0x0, r_rspdata = 0x0}}, sr_flags = 0} tag = 108 opidx = SLAP_OP_MODRDN conn = 0x7ffff7e6ae90 memctx = 0x7ffd74002bf0 memctx_null = 0x0 memsiz = 1048576 __PRETTY_FUNCTION__ = "connection_operation" #3 0x00000000004408f8 in connection_read_thread (ctx=0x7ffd81a5fc40, argv=0x10) at connection.c:1270 rc = 0 cri = {op = 0x7ffd740026b0, func = 0x0, arg = 0x0, ctx = 0x7ffd81a5fc40, nullop = 0} s = 16 #4 0x00007ffff7b89e5e in ldap_int_thread_pool_wrapper (xpool=0x7fa480) at tpool.c:945 pq = 0x7fa480 pool = 0x7fa370 task = 0x7ffd7c0008c0 work_list = 0x7fa4f0 ctx = {ltu_pq = 0x7fa480, ltu_id = 140726778595072, ltu_key = {{ltk_key = 0x43fd34 <conn_counter_init>, ltk_data = 0x7ffd74002ae0, ltk_free = 0x43fb86 <conn_counter_destroy>}, {ltk_key = 0x4b9a08 <slap_sl_mem_init>, ltk_data = 0x7ffd74002bf0, ltk_free = 0x4b982d <slap_sl_mem_destroy>}, {ltk_key = 0x45c06b <slap_op_free>, ltk_data = 0x0, ltk_free = 0x45bfbe <slap_op_q_destroy>}, {ltk_key = 0x0, ltk_data = 0x0, ltk_free = 0x0} <repeats 23 times>, {ltk_key = 0x0, ltk_data = 0xe81b289de6cb1252, ltk_free = 0x80}, {ltk_key = 0x0, ltk_data = 0x0, ltk_free = 0x0}, {ltk_key = 0x0, ltk_data = 0x0, ltk_free = 0x0}, {ltk_key = 0x0, ltk_data = 0x0, ltk_free = 0x0}, {ltk_key = 0x0, ltk_data = 0x0, ltk_free = 0x0}, {ltk_key = 0x0, ltk_data = 0x0, ltk_free = 0x0}}} kctx = 0x0 i = 32 keyslot = 586 hash = 2858034762 pool_lock = 0 freeme = 0 __PRETTY_FUNCTION__ = "ldap_int_thread_pool_wrapper" #5 0x00007ffff5dbf062 in start_thread (arg=0x7ffd81a60700) at pthread_create.c:312 __res = <optimized out> pd = 0x7ffd81a60700 now = <optimized out> unwind_buf = {cancel_jmp_buf = {{jmp_buf = {140726778595072, 1720423256181903954, 1, 140737354125408, 0, 140726778595072, -1721737773892038062, -1720445005621816750}, mask_was_saved = 0}}, priv = {pad = {0x0, 0x0, 0x0, 0x0}, data = { prev = 0x0, cleanup = 0x0, canceltype = 0}}} not_first_call = <optimized out> pagesize_m1 = <optimized out> sp = <optimized out> freesize = <optimized out> __PRETTY_FUNCTION__ = "start_thread" #6 0x00007ffff5af2bfd in clone () at ../sysdeps/unix/sysv/linux/x86_64/clone.S:111 No locals. The problem is a dereference of the missing equality rule: (gdb) p desc->ad_type $1 = (AttributeType *) 0x83ec70 (gdb) p desc->ad_type->sat_equality $2 = (MatchingRule *) 0x0

1 0

Re: (ITS#7845) slapd debug in the background
by quanah＠zimbra.com 07 May '14

07 May '14

--On April 29, 2014 at 2:21:18 AM +0000 wingcheungma(a)gmail.com wrote: > Full_Name: Wing Cheung Ma > Version: 2.4.23 > OS: Rhel5 > URL: ftp://ftp.openldap.org/incoming/ > Submission from: (NULL) (54.240.196.185) This ITS system is for reporting bugs, not asking usage questions. Please direct usage questions to the openldap-technical(a)openldap.org list. This ITS will be closed. --Quanah -- Quanah Gibson-Mount Server Architect Zimbra, Inc -------------------- Zimbra :: the leader in open source messaging and collaboration

1 0

(ITS#7849) MMR can lose track of its serverID, go into loop
by quanah＠OpenLDAP.org 07 May '14

07 May '14

Full_Name: Quanah Gibson-Mount Version: 2.4.39 OS: Linux 2.6 URL: ftp://ftp.openldap.org/incoming/ Submission from: (NULL) (107.207.38.73) 2 reports now of MMR (delta-syncrepl specifically at this point) going into endless loops replicating changes. In both cases, it appears that all the servers lose track of their serverIDs (reverting to 000), which causes the change(s) to never get dropped, causing all servers to go into endless loops, eating up CPU and causing massive growth of the accesslog DB.

1 0

Re: (ITS#7848) openldap n-way multi-master replication
by quanah＠zimbra.com 05 May '14

05 May '14

--On Tuesday, May 06, 2014 2:47 AM +0000 idpbg-it-dba(a)mail.foxconn.com wrote: > Full_Name: Robert.YQ.Feng > Version: 2.4.23-31 Stop wasting your time using RHEL's utterly broken packages. Please do not file bug reports on builds that are years out of date. Please do use a current, sanely built and linked package of OpenLDAP, such as the builds from Symas or the LTB project. Thanks. This ITS will be closed. --Quanah -- Quanah Gibson-Mount Server Architect Zimbra, Inc. -------------------- Zimbra :: the leader in open source messaging and collaboration

1 0

Jump to page:

2025

2024

2023

2022

2021

2020

2019

2018

2017

2016

2015

2014

2013

2012

2011

2010

2009

2008

2007

2006

openldap-bugs