Fedora Project 389 Directory Server 1.4.0.13

CPE Details

Fedora Project 389 Directory Server 1.4.0.13
fedoraproject
389_directory_server
1.4.0.13
2018-11-13
16h57 +00:00
2018-11-13
16h57 +00:00
CPE NVD
Alerte pour un CPE
Stay informed of any changes for a specific CPE.
Notifications manage

CPE Name: cpe:2.3:a:fedoraproject:389_directory_server:1.4.0.13:*:*:*:*:*:*:*

Informations

Vendor

fedoraproject

Product

389_directory_server

Version

1.4.0.13

Related CVE

Open and find in CVE List

CVE ID Published Description Score Severity
CVE-2019-10224 2019-11-24 23h00 +00:00 A flaw has been found in 389-ds-base versions 1.4.x.x before 1.4.1.3. When executed in verbose mode, the dscreate and dsconf commands may display sensitive information, such as the Directory Manager password. An attacker, able to see the screen or record the terminal standard error output, could use this flaw to gain sensitive information.
4.6
Medium
CVE-2019-10171 2019-08-02 11h49 +00:00 It was found that the fix for CVE-2018-14648 in 389-ds-base, versions 1.4.0.x before 1.4.0.17, was incorrectly applied in RHEL 7.5. An attacker would still be able to provoke excessive CPU consumption leading to a denial of service.
7.5
High
CVE-2019-3883 2019-04-16 22h00 +00:00 In 389-ds-base up to version 1.4.1.2, 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.
7.5
High
CVE-2018-14648 2018-09-28 11h00 +00:00 A flaw was found in 389 Directory Server. A specially crafted search query could lead to excessive CPU consumption in the do_search() function. An unauthenticated attacker could use this flaw to provoke a denial of service.
7.5
High
CVE-2018-14624 2018-09-06 11h00 +00:00 A vulnerability was discovered in 389-ds-base through versions 1.3.7.10, 1.3.8.8 and 1.4.0.16. The lock controlling the error log was not correctly used when re-opening the log file in log__error_emergency(). An attacker could send a flood of modifications to a very large DN, which would cause slapd to crash.
7.5
High