Bug 1693612 (CVE-2019-3883)

Summary:	CVE-2019-3883 389-ds-base: DoS via hanging secured connections
Product:	[Other] Security Response	Reporter:	Cedric Buissart <cbuissar>
Component:	vulnerability	Assignee:	Red Hat Product Security <security-response-team>
Status:	CLOSED ERRATA	QA Contact:
Severity:	medium	Docs Contact:
Priority:	medium
Version:	unspecified	CC:	ascheel, carnil, jpadman, lkrispen, mhonek, mreynolds, nkinder, rmeggins, security-response-team, spichugi, tbordaz, vashirov, william
Target Milestone:	---	Keywords:	Security
Target Release:	---
Hardware:	All
OS:	Linux
Whiteboard:
Fixed In Version:	389-ds-base 1.4.0.24, 389-ds-base 1.4.1.4	Doc Type:	If docs needed, set a value
Doc Text:	It was found that encrypted connections did not honor the 'ioblocktimeout' parameter to end blocking requests. As a result, an unauthenticated attacker could repeatedly start a sufficient number of encrypted connections to block all workers, resulting in a denial of service.	Story Points:	---
Clone Of:		Environment:
Last Closed:	2019-07-29 19:18:33 UTC	Type:	---
Regression:	---	Mount Type:	---
Documentation:	---	CRM:
Verified Versions:		Category:	---
oVirt Team:	---	RHEL 7.3 requirements from Atomic Host:
Cloudforms Team:	---	Target Upstream Version:
Embargoed:
Bug Depends On:	1668457, 1699043, 1719720
Bug Blocks:	1690835

Description Cedric Buissart 2019-03-28 10:06:27 UTC

In 389-ds-base, requests are handled by workers threads. Each sockets will be waited by the worker for at most 'ioblocktimeout' seconds.
However this timeout applies only for un-encrypted requests. Connections using SSL/TLS are not taking this timeout into account during reads, and may hang longer.

An unauthenticated attacker could repeatedly create hanging LDAP requests to hang all the workers, resulting in a Denial of Service.

Comment 5 Salvatore Bonaccorso 2019-04-13 07:43:33 UTC

Hi

Is there any further references for this issue? Upstream issue or fixing commits? Thanks already for any hints!

Regards,
Salvatore

Comment 6 William Brown 2019-04-15 00:49:44 UTC

Upstream does not appear to have been contacted about this issue. Perhaps the developers of 389 at redhat have? We have had some issues in the past with communication of security issues though.

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

I will be investigating this soon.

Comment 7 thierry bordaz 2019-04-15 08:16:03 UTC

Created attachment 1555159 [details]
Make sure secure connection enforce the ioblocktimeout

Comment 8 Cedric Buissart 2019-04-16 08:21:34 UTC

Hello,

There is a proposed patch uploaded via comment 7.

Comment 9 Cedric Buissart 2019-06-27 09:41:49 UTC

Upstream fixes :

1.3.8 branch : 
 * https://pagure.io/389-ds-base/c/e26704f0079

1.3.9 branch :
 * https://pagure.io/389-ds-base/c/dd4b69b5
 * https://pagure.io/389-ds-base/c/9a89e779
 * https://pagure.io/389-ds-base/c/33ac4f5a

1.4.0 branch :
 * https://pagure.io/389-ds-base/c/fcf2b5d
 * https://pagure.io/389-ds-base/c/4950a3e
 * https://pagure.io/389-ds-base/c/7b0e7f6

master branch :
 * https://pagure.io/389-ds-base/c/4d9cc24da
 * https://pagure.io/389-ds-base/c/6d080a0a
 * https://pagure.io/389-ds-base/c/f35ad371
 * https://pagure.io/389-ds-base/c/f20e982c

Comment 10 errata-xmlrpc 2019-07-29 15:15:49 UTC

This issue has been addressed in the following products:

  Red Hat Enterprise Linux 7

Via RHSA-2019:1896 https://access.redhat.com/errata/RHSA-2019:1896

Comment 11 Product Security DevOps Team 2019-07-29 19:18:33 UTC

This bug is now closed. Further updates for individual products will be reflected on the CVE page(s):

https://access.redhat.com/security/cve/cve-2019-3883

Comment 12 errata-xmlrpc 2019-11-05 20:46:01 UTC

This issue has been addressed in the following products:

  Red Hat Enterprise Linux 8

Via RHSA-2019:3401 https://access.redhat.com/errata/RHSA-2019:3401