Denial of service attack.
Customer is doing a particular query that provokes (apparently) a denial of service.
We can see this in the pstack:
Lost of threads in this stacktrace:
Thread 9 (Thread 0x7feb35ef3700 (LWP 6399)): #0 0x00007feb8a3a27d3 in slapi_ch_array_add_ext () from /usr/lib64/dirsrv/libslapd.so.0 #1 0x000055c738ec9723 in do_search () #2 0x000055c738eb8ab4 in connection_threadmain () #3 0x00007feb88750bab in _pt_root () from /lib64/libnspr4.so #4 0x00007feb880f0dd5 in start_thread () from /lib64/libpthread.so.0 #5 0x00007feb8779db3d in clone () from /lib64/libc.so.6
and this lock:
Thread 18 (Thread 0x7feb3a6fc700 (LWP 6390)): #0 0x00007feb880f74cd in __lll_lock_wait () from /lib64/libpthread.so.0 #1 0x00007feb880f40c2 in pthread_rwlock_rdlock () from /lib64/libpthread.so.0 #2 0x00007feb8a39dc66 in attr_syntax_get_by_oid_locking_optional () from /usr/lib64/dirsrv/libslapd.so.0 #3 0x00007feb8a39f25b in slapi_attr_syntax_normalize_ext () from /usr/lib64/dirsrv/libslapd.so.0 #4 0x000055c738ec9700 in do_search () #5 0x000055c738eb8ab4 in connection_threadmain () #6 0x00007feb88750bab in _pt_root () from /lib64/libnspr4.so #7 0x00007feb880f0dd5 in start_thread () from /lib64/libpthread.so.0 #8 0x00007feb8779db3d in clone () from /lib64/libc.so.6
Version-Release number of selected component (if applicable): 389-ds-base-1.3.6.1-29.el7_4.x86_64
How reproducible:
A client connects to the ldap interface & sends in a sequence two kinds of messages in a loop. The first message is a valid bind that is actually used to monitor the availability of the interface. The second message is a Ldap search but it is an overflow with specific (malformed) values as well, in scope-universal-pri-10_V field & derefAliases-Universl-pri-10-V field. These two messages are being sent in a loop & after some iteration the interface becomes unresponsive to the bind request.
Metadata Update from @mreynolds: - Custom field component adjusted to None - Custom field origin adjusted to None - Custom field reviewstatus adjusted to None - Custom field rhbz adjusted to https://bugzilla.redhat.com/show_bug.cgi?id=1624004 - Custom field type adjusted to None - Custom field version adjusted to None
Metadata Update from @mreynolds: - Issue close_status updated to: fixed - Issue status updated to: Closed (was: Open)
e2810e7..a49bd03 master -> master
dc48bfd..5fc374b 389-ds-base-1.3.8 -> 389-ds-base-1.3.8
9f28620..c8ec6e5 389-ds-base-1.3.7 -> 389-ds-base-1.3.7
@mreynolds be aware the fix is incomplete and triggers a failure for freeipa (see FailedQA on the BZ). It requires an additional fix to relax the checking of empty attributes.
Metadata Update from @tbordaz: - Issue status updated to: Open (was: Closed)
Errr this fix was NOT in the original bugzilla that had the other patches. I'll rebuild later today...
c8ec6e5..722a6f8 389-ds-base-1.3.7 -> 389-ds-base-1.3.7
3feba4b..bdb1af6 389-ds-base-1.3.8 -> 389-ds-base-1.3.8
068a00f..a636979 master -> master
Commit 2f5daa7 relates to this ticket
389-ds-base is moving from Pagure to Github. This means that new issues and pull requests will be accepted only in 389-ds-base's github repository.
This issue has been cloned to Github and is available here: - https://github.com/389ds/389-ds-base/issues/3028
If you want to receive further updates on the issue, please navigate to the github issue and click on subscribe button.
subscribe
Thank you for understanding. We apologize for all inconvenience.
Metadata Update from @spichugi: - Issue close_status updated to: wontfix (was: fixed)
Login to comment on this ticket.