Bug 1588056 – CVE-2018-10850 389-ds-base: race condition on reference counter leads to DoS using persistent search

Bugzilla will be upgraded to version 5.0 on a still to be determined date in the near future. The original upgrade date has been delayed.

Bug 1588056 - (CVE-2018-10850) CVE-2018-10850 389-ds-base: race condition on reference counter leads to DoS using persistent search

Summary:	CVE-2018-10850 389-ds-base: race condition on reference counter leads to DoS ...

Status:	CLOSED ERRATA

Aliases:	CVE-2018-10850

Product:	Security Response
Classification:	Other
Component:	vulnerability (Show other bugs)
Sub Component:
Version:	unspecified
Hardware:	All Linux

Priority	medium Severity medium
Target Milestone:	---
Target Release:	---
Assigned To:	Red Hat Product Security
QA Contact:
Docs Contact:

URL:
Whiteboard:	impact=moderate,public=20180606,repor...
Keywords:	Security

Depends On:	1588057 1588059 1628676
Blocks:	1566206
	Show dependency tree / graph

Reported:	2018-06-06 10:26 EDT by Cedric Buissart
Modified:	2018-10-18 14:07 EDT (History)
CC List:	4 users (show)

See Also:
Fixed In Version:	389-ds-base 1.4.0.10, 389-ds-base 1.3.8.3
Doc Type:	If docs needed, set a value
Doc Text:	A race condition was found in the way 389-ds-base handles persistent search, resulting in a crash if the server is under load. An anonymous attacker could use this flaw to trigger a denial of service.
Story Points:	---
Clone Of:
Environment:
Last Closed:	2018-10-18 14:07:20 EDT
Type:	---
Regression:	---
Mount Type:	---
Documentation:	---
CRM:
Verified Versions:
Category:	---
oVirt Team:	---
RHEL 7.3 requirements from Atomic Host:
Cloudforms Team:	---

Attachments	(Terms of Use)
Add an attachment (proposed patch, testcase, etc.)

External Trackers
Tracker	ID	Priority	Status	Summary	Last Updated
Red Hat Product Errata	RHSA-2018:2757	None	None	None	2018-09-25 15:05 EDT

Groups: None (edit)

Description Cedric Buissart 2018-06-06 10:26:41 EDT

The bug is related to incoming connection handling in DS. A connection data structure contains a refcnt. The refcnt accounts the number of pending requests. When a connection needs to be cleanup (upon closure, timeout...) the core server waits for refcnt to be 0. It basically waits for all pending requests to complete before cleaning the structure.

The refcnt does not account specific LDAP request (persistent search), so if an event occurs on the connection (closure) the core server may reset the structure although a request is still going on. 

Anonymous user are allowed to trigger a persistent search so in theory anyone sending persistent search and closing  the connection hits that bug. 
Under normal use, most of the time the problem is not detected. Sometime there are error written in the log when an invalid refcnt is found. But depending on dispatch dynamic of the threads handling connection event it can crash.

Comment 4 Cedric Buissart 2018-06-06 11:04:34 EDT

Acknowledgments:

Name: Thierry Bordaz (Red Hat)

Comment 5 Cedric Buissart 2018-06-11 05:16:24 EDT

Upstream fix :
 - Ticket 49768 - Under network intensive load persistent search can erronously decrease connection refcnt
https://pagure.io/389-ds-base/c/8f04487f99a

Comment 6 Cedric Buissart 2018-06-11 05:24:07 EDT

External References:

https://pagure.io/389-ds-base/issue/49768

Comment 8 errata-xmlrpc 2018-09-25 15:05:44 EDT

This issue has been addressed in the following products:

  Red Hat Enterprise Linux 7

Via RHSA-2018:2757 https://access.redhat.com/errata/RHSA-2018:2757

Note You need to log in before you can comment on or make changes to this bug.