Bug 19304 - 389-ds-base new security issue CVE-2016-4992
Summary: 389-ds-base new security issue CVE-2016-4992
Alias: None
Product: Mageia
Classification: Unclassified
Component: Security (show other bugs)
Version: 5
Hardware: All Linux
Priority: Normal normal
Target Milestone: ---
Assignee: QA Team
QA Contact: Sec team
URL: http://lwn.net/Vulnerabilities/699805/
Whiteboard: has_procedure MGA5-64-OK advisory
Keywords: validated_update
Depends on:
Reported: 2016-09-07 19:45 CEST by David Walser
Modified: 2016-10-21 16:49 CEST (History)
5 users (show)

See Also:
Source RPM: 389-ds-base-
Status comment:


Description David Walser 2016-09-07 19:45:35 CEST
Fedora has issued an advisory on August 6:

The issue is fixed in

The issue might affect 1.3.5.x and be fixed in as well.
David Walser 2016-09-07 19:45:49 CEST

Whiteboard: (none) => MGA5TOO

Comment 1 Marja Van Waes 2016-09-08 11:11:11 CEST
Assigning to all packagers collectively, since, to the best of my knowledge, the registered maintainer is unavailable.

CC: (none) => marja11
Assignee: bugsquad => pkg-bugs

Comment 2 Mike Rambo 2016-09-29 18:10:00 CEST
Changed version from cauldron to 5 as this applies to both.

389-ds-base- has been uploaded for cauldron/6.

CC: (none) => mrambo
Version: Cauldron => 5
Whiteboard: MGA5TOO => (none)

Comment 3 Mike Rambo 2016-10-03 19:46:15 CEST
Patched package uploaded for Mageia 5.

Testing procedures:


Updated 389-ds-base package fixes security vulnerability:

A vulnerability in 389-ds-base was found that allows to bypass limitations 
for compare and read operations specified by Access Control Instructions.
When having LDAP sub-tree with some existing objects and having BIND DN 
which have no privileges over objects inside the sub-tree, unprivileged
user can send LDAP ADD operation specifying an object in (supposedly)
inaccessible sub-tree. The returned error messages discloses the
information when the queried object exists having the specified value.
Attacker can use this flaw to guess values of RDN component by repeating
the above process (CVE-2016-4992).


Updated packages in core/updates_testing:

from 389-ds-base-

Assignee: pkg-bugs => qa-bugs

Mike Rambo 2016-10-03 19:51:39 CEST

Whiteboard: (none) => has_procedure

Comment 4 Lewis Smith 2016-10-11 21:24:00 CEST
Testing M5-64 real hardware
 # cat /etc/hosts           localhost.localdomain localhost
Following procedure https://bugs.mageia.org/show_bug.cgi?id=16928#c7 except I already had the package installed and running, so skipped the installation part.

BEFORE update
 # systemctl status dirsrv@localhost
â dirsrv@localhost.service - 389 Directory Server localhost.
   Loaded: loaded (/usr/lib/systemd/system/dirsrv@.service; enabled)
   Active: active (running) since Maw 2016-10-11 20:55:40 CEST; 10s ago
  Process: 4561 ExecStart=/usr/sbin/ns-slapd -D /etc/dirsrv/slapd-%i -i /var/run/dirsrv/slapd-%i.pid -w /var/run/dirsrv/slapd-%i.startpid (code=exited, status=0/SUCCESS)
 Main PID: 4610 (ns-slapd)
   CGroup: /system.slice/system-dirsrv.slice/dirsrv@localhost.service
           ââ4610 /usr/sbin/ns-slapd -D /etc/dirsrv/slapd-localhost -i /var/r...
[shown in full because it changed slightly]

# netstat -pant | grep 389
tcp6       0      0 :::389                  :::*                    LISTEN      4610/ns-slapd       

 # ldapsearch -x -h localhost -s base -b ""  "objectclass=*"
# extended LDIF
# LDAPv3
# base <> with scope baseObject
# filter: objectclass=*
# requesting: ALL
objectClass: top
defaultnamingcontext: dc=localdomain
dataversion: 020161011185541
netscapemdsuffix: cn=ldap://dc=localhost,dc=localdomain:389
# search result
search: 2
result: 0 Success
# numResponses: 2
# numEntries: 1

AFTER update:
Note that the library is not in the Comment 3 pkg list; but it was in Updates Testing, and was automatically included when choosing the base package.

 # systemctl restart dirsrv@localhost

 # systemctl status dirsrv@localhost
â dirsrv@localhost.service - 389 Directory Server localhost.
   Loaded: loaded (/usr/lib/systemd/system/dirsrv@.service; enabled)
   Active: active (running) since Maw 2016-10-11 21:03:05 CEST; 13s ago
  Process: 3377 ExecStopPost=/bin/rm -f /var/run/dirsrv/slapd-%i.pid (code=exited, status=0/SUCCESS)
  Process: 3426 ExecStart=/usr/sbin/ns-slapd -D /etc/dirsrv/slapd-%i -i /var/run/dirsrv/slapd-%i.pid -w /var/run/dirsrv/slapd-%i.startpid (code=exited, status=0/SUCCESS)
 Main PID: 3448 (ns-slapd)
   CGroup: /system.slice/system-dirsrv.slice/dirsrv@localhost.service
           ââ3448 /usr/sbin/ns-slapd -D /etc/dirsrv/slapd-localhost -i /var/r...
[Note the additional 2nd Process info line compared to before the update].

 # netstat -pant | grep 389
[O/P essentially identical]

 # ldapsearch -x -h localhost -s base -b ""  "objectclass=*"
[O/P essentially identical]

This update looks OK.

CC: (none) => lewyssmith
Whiteboard: has_procedure => has_procedure MGA5-64-OK

Dave Hodgins 2016-10-21 05:25:07 CEST

Keywords: (none) => validated_update
Whiteboard: has_procedure MGA5-64-OK => has_procedure MGA5-64-OK advisory
CC: (none) => davidwhodgins, sysadmin-bugs

Comment 5 Mageia Robot 2016-10-21 16:49:06 CEST
An update for this issue has been pushed to the Mageia Updates repository.


Resolution: (none) => FIXED

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