389-ds-base (SL7)

Synopsis: Moderate: 389-ds-base security and bug fix update
Advisory ID: SLSA-2017:2569-1
Issue Date: 2017-09-05
CVE Numbers: CVE-2017-7551

Security Fix(es):

* A flaw was found in the way 389-ds-base handled authentication attempts
against locked accounts. A remote attacker could potentially use this flaw
to continue password brute-forcing attacks against LDAP accounts, thereby
bypassing the protection offered by the directory server’s password
lockout policy. (CVE-2017-7551)

Bug Fix(es):

* In a multi-replication environments, if operations in one back end
triggered updates in another back end, the Replica Update Vector (RUV) of
the back end was incorrect and replication failed. This fix enables
Directory Server to handle Change Sequence Number (CSN) pending lists
across multiple back ends. As a result, replication works correctly.

* Due to a low default entry cache size value, the Directory Server
database had to resolve many deadlocks during resource-intensive tasks. In
certain situations, this could result in a “DB PANIC” error and the server
no longer responded to requests. After the server was restarted, Directory
Server started with a delay to recover the database. However, this
recovery could fail, and the database could corrupt. This patch increases
the default entry cache size in the nsslapd-cachememsize parameter to 200
MB. As a result, out-of-lock situations or “DB PANIC” errors no longer
occur in the mentioned scenario.

* Previously, if replication was enabled and a changelog file existed,
performing a backup on this master server failed. This update sets the
internal options for correctly copying a file. As a result, creating a
backup now succeeds in the mentioned scenario.

* In certain situations, if the server was previously abruptly shut down,
the /etc/dirsrv//dse.ldif configuration file became
corrupted. As a consequence, Directory Server failed to start. With this
patch, the server now calls the fsync() function before shutting down to
force the file system to write any changes to the disk. As a result, the
configuration no longer becomes corrupted, regardless how the server gets


– Scientific Linux Development Team