Hide Forgot
Description of problem: Any authenticated user doing a search using ldapsearch with extended controls for server side sorting is bringing down the ldap server itself. Version-Release number of selected component (if applicable): 389-ds-base-1.3.7.5-18.el7.x86_64.rpm How reproducible: - Always reproduciable Steps to Reproduce: - Just install the rpm with some sample data - Run the below ldapsearch ldapsearch -D"cn=Directory Manager" -W -E sss=uid:2.5.13.3 Actual results: # ldapsearch -D"cn=Directory Manager" -W -E sss=uid:2.5.13.3 > /dev/null Enter LDAP Password: ldap_result: Can't contact LDAP server (-1) # - System logs show the server is no longer responding Jul 21 14:33:37 ipa-lab-vm-01 ns-slapd: [21/Jul/2018:14:33:37.566302429 +0000] - WARN - default_mr_indexer_create - Plugin [caseExactIA5Match] does not handle 2.5.13.3 Jul 21 14:33:37 ipa-lab-vm-01 ns-slapd: [21/Jul/2018:14:33:37.571733926 +0000] - WARN - default_mr_indexer_create - Plugin [caseIgnoreIA5Match] does not handle 2.5.13.3 Jul 21 14:33:38 ipa-lab-vm-01 kernel: ns-slapd[31886]: segfault at 0 ip 00007f301a986d5d sp 00007f2fd38057b0 error 4 in libback-ldbm.so[7f301a90d000+a0000] Jul 21 14:33:38 ipa-lab-vm-01 systemd: dirsrv@XXXXXXXXXXXXX-NET.service: main process exited, code=killed, status=11/SEGV Jul 21 14:33:38 ipa-lab-vm-01 systemd: Unit dirsrv@XXXXXXXXXXX-NET.service entered failed state. Jul 21 14:33:38 ipa-lab-vm-01 systemd: dirsrv@XXXXXXXXX-NET.service failed. Expected results: - If the ldapserver can not provide extended controls, it should through error, but should not crash - This issue is allowing any authenticated user to bring down the server, by just running a query Additional info:
I can not reproduce this on any version of DS (1.3.7, 1.3.8, and 1.4.0) based on the bug description. Please provide exact steps to reproduce the issue.
Mark, I can reproduce this in IPA context (default install) with 389-ds-base-1.3.8.4-5.el7.x86_64: Program received signal SIGSEGV, Segmentation fault. [Switching to Thread 0x7fa1e064f700 (LWP 30759)] attr_value_lowest (values=0x0, compare_fn=compare_fn@entry=0x7fa206367490 <slapi_berval_cmp>) at ldap/servers/slapd/back-ldbm/sort.c:421 421 struct berval *lowest_so_far = values[0]; (gdb) bt #0 0x00007fa1f7ff3b0d in attr_value_lowest (values=0x0, compare_fn=compare_fn@entry=0x7fa206367490 <slapi_berval_cmp>) at ldap/servers/slapd/back-ldbm/sort.c:421 #1 0x00007fa1f7ff3b72 in sort_attr_compare (value_a=<optimized out>, value_b=0x0, compare_fn=0x7fa206367490 <slapi_berval_cmp>) at ldap/servers/slapd/back-ldbm/sort.c:444 #2 0x00007fa1f7ff3ca7 in compare_entries_sv (id_a=id_a@entry=0x55adbd44561c, id_b=id_b@entry=0x55adbd445618, s=s@entry=0x55adbef883c0, error=error@entry=0x7fa1e0649b3c, bc=<optimized out>, bc=<optimized out>) at ldap/servers/slapd/back-ldbm/sort.c:556 #3 0x00007fa1f7ff4228 in shortsort (s=0x55adbef883c0, hi=0x55adbd445624, lo=0x55adbd445618, bc=0x7fa1e0649d80) at ldap/servers/slapd/back-ldbm/sort.c:828 #4 0x00007fa1f7ff4228 in slapd_qsort (bc=bc@entry=0x7fa1e0649d80, list=list@entry=0x55adbd445600, s=s@entry=0x55adbef883c0) at ldap/servers/slapd/back-ldbm/sort.c:689 #5 0x00007fa1f7ff4440 in sort_candidates (be=0x55adbd351e10, lookthrough_limit=lookthrough_limit@entry=-1, expire_time=expire_time@entry=0x7fa1e0649f00, pb=pb@entry=0x55adbe787f20, candidates=0x55adbd445600, s=0x55adbef883c0, sort_error_type=sort_error_type@entry=0x7fa1e0649ed8) at ldap/servers/slapd/back-ldbm/sort.c:197 #6 0x00007fa1f7fe4bed in ldbm_back_search (pb=0x55adbe787f20) at ldap/servers/slapd/back-ldbm/ldbm_search.c:705 #7 0x00007fa20635bf42 in op_shared_search (pb=pb@entry=0x55adbe787f20, send_result=send_result@entry=1) at ldap/servers/slapd/opshared.c:763 #8 0x000055adbb88383e in do_search (pb=pb@entry=0x55adbe787f20) at ldap/servers/slapd/search.c:335 #9 0x000055adbb8716aa in connection_dispatch_operation (pb=0x55adbe787f20, op=0x55adbee9a1c0, conn=0x55adbe81f000) at ldap/servers/slapd/connection.c:649 #10 0x000055adbb8716aa in connection_threadmain () at ldap/servers/slapd/connection.c:1785 #11 0x00007fa20413dbab in _pt_root (arg=0x55adbe7b9320) at ../../../nspr/pr/src/pthreads/ptthread.c:201 #12 0x00007fa203adddd5 in start_thread (arg=0x7fa1e064f700) at pthread_create.c:307 #13 0x00007fa203189ead in clone () at ../sysdeps/unix/sysv/linux/x86_64/clone.S:111
Upstream ticket: https://pagure.io/389-ds-base/issue/49890
Security flaw bug: BZ#1613606
Build tested: 389-ds-base-1.3.8.4-10.el7.x86_64 [1] Search no longer crashes the server, but it doesn't return sorted results per matching rule [root@server ds]# ldapsearch -xLLL -D cn=Directory\ Manager -w Secret123 -b cn=users,cn=accounts,dc=ipa,dc=test -E sss=uid:2.5.13.3 "(uid=tuser*)" uid | grep uid: uid: tuser2 uid: tuser3 uid: tuser [root@server ds]# ldapsearch -xLLL -D cn=Directory\ Manager -w Secret123 -b cn=users,cn=accounts,dc=ipa,dc=test -E sss=-uid:2.5.13.3 "(uid=tuser*)" uid | grep uid: uid: tuser2 uid: tuser3 uid: tuser [2] Although regular server side sort without matching rule works: [root@server ds]# ldapsearch -xLLL -D cn=Directory\ Manager -w Secret123 -b cn=users,cn=accounts,dc=ipa,dc=test -E sss=-uid "(uid=tuser*)" uid | grep uid: uid: tuser3 uid: tuser2 uid: tuser [root@server ds]# ldapsearch -xLLL -D cn=Directory\ Manager -w Secret123 -b cn=users,cn=accounts,dc=ipa,dc=test -E sss=uid "(uid=tuser*)" uid | grep uid: uid: tuser uid: tuser2 uid: tuser3 I'll open a separate bugzilla for [1]. Since search no longer crashes the server, marking as VERIFIED.
Since the problem described in this bug report should be resolved in a recent advisory, it has been closed with a resolution of ERRATA. For information on the advisory, and where to find the updated files, follow the link below. If the solution does not work for you, open a new bug report. https://access.redhat.com/errata/RHSA-2018:3127