A security issue in 389-ds-base has been announced: http://openwall.com/lists/oss-security/2018/03/06/2 The RedHat bug linked from the message above has a patch. Mageia 5 and Mageia 6 are also affected.
Whiteboard: (none) => MGA6TOOCC: (none) => mrambo
Assigning to all packagers collectively, since there is no registered maintainer for this package.
Assignee: bugsquad => pkg-bugsCC: (none) => marja11
Advisory ======== 389-ds-base has been updated to fix a security issue. CVE-2018-1054 A flaw was found in 389 Directory Server that affects all versions. An improper handling of the search feature with an extended filter, when read access on <attribute_name> is enabled, in SetUnicodeStringFromUTF_8 function in collate.c, can lead to out-of-bounds memory operations. This may allow a remote unauthenticated attacker to trigger a server crash, thus resulting in denial of service. References ========== http://openwall.com/lists/oss-security/2018/03/06/2 Files ===== These files has been uploaded to core/updates_testing: 389-ds-base-1.3.5.17-1.2.mga6 lib64389-ds-base0-1.3.5.17-1.3.mga6 lib64389-ds-base-devel-1.3.5.17-1.3.mga6 389-ds-base-snmp-1.3.5.17-1.3.mga6 from 389-ds-base-1.3.5.17-1.3.mga6.src.rpm
CVE: (none) => CVE-2018-1054Assignee: pkg-bugs => qa-bugsVersion: Cauldron => 6CC: (none) => smelrorWhiteboard: MGA6TOO => (none)
389-ds-base has also been updated in Cauldron with the same patch.
Advisory uploaded. Procedure: bug 21671 comment 4
Keywords: (none) => advisory, has_procedure
Mageia 6 :: x86_64 Forewarned by bug 21671#c5 made sure that /etc/hosts contained an entry for localhost.localdomain. Clean update of these packages: - 389-ds-base-1.3.5.17-1.3.mga6.x86_64 - 389-ds-base-snmp-1.3.5.17-1.3.mga6.x86_64 - lib64389-ds-base-devel-1.3.5.17-1.3.mga6.x86_64 - lib64389-ds-base0-1.3.5.17-1.3.mga6.x86_64 Referred to tests in https://bugs.mageia.org/show_bug.cgi?id=21671 # setup-ds.pl Changed hostname from difda to localhost.localdomain. Thereafter used defaults. # systemctl start dirsrv@localhost # systemctl status dirsrv@localhost ● dirsrv@localhost.service - 389 Directory Server localhost. Loaded: loaded (/usr/lib/systemd/system/dirsrv@.service; enabled; vendor pres Active: active (running) since Wed 2018-03-07 17:38:03 GMT; 59s ago Process: 1167 ExecStartPre=/usr/sbin/ds_systemd_ask_password_acl /etc/dirsrv/s Main PID: 1174 (ns-slapd) Status: "slapd started: Ready to process requests" CGroup: /system.slice/system-dirsrv.slice/dirsrv@localhost.service └─1174 /usr/sbin/ns-slapd -D /etc/dirsrv/slapd-localhost -i /var/r # systemctl start dirsrv.localhost Thanks again to Claire for blazing a trail. # netstat -pant | grep 389 tcp6 0 0 :::389 :::* LISTEN 1174/ns-slapd # ldapsearch -x -h localhost -s base -b "" "objectclass=*" # extended LDIF # # LDAPv3 # base <> with scope baseObject # filter: objectclass=* # requesting: ALL # # dn: objectClass: top defaultnamingcontext: dc=localdomain dataversion: 020180307173803 netscapemdsuffix: cn=ldap://dc=localhost,dc=localdomain:389 # search result search: 2 result: 0 Success # numResponses: 2 # numEntries: 1 $ id dirsrv uid=972(dirsrv) gid=972(dirsrv) groups=972(dirsrv) The results parallel those in previous tests so this can be given an OK.
CC: (none) => tarazed25Whiteboard: (none) => MGA6-64-OK
And be validated!
Keywords: (none) => validated_updateCC: (none) => sysadmin-bugs
An update for this issue has been pushed to the Mageia Updates repository. https://advisories.mageia.org/MGASA-2018-0162.html
Status: NEW => RESOLVEDResolution: (none) => FIXED
Mageia6, x86_64 Treading old ground here. Referring to previous reports on this bug (Claire and lewis) set up the dirserver before updating using hostname difda.temp. That worked fine but the hostname needed to be reverted to difda before MageiaUpdate would work. # hostname difda.temp # echo difda.temp > /etc/hostname # echo "192.168.1.103 difda.temp" >> /etc/hosts This did not work so overwrote difda by difda.temp. # setup-ds.pl Directory server network port = 29690 (previous values in use). server identifier = tarazed (difda already in use) Success at last. # systemctl start dirsrv@difda # systemctl status dirsrv@difda ● dirsrv@difda.service - 389 Directory Server difda. Loaded: loaded (/usr/lib/systemd/system/dirsrv@.service; enabled; vendor pres Active: active (running) since Mon 2018-04-02 18:25:20 BST; 26min ago # netstat -pant | grep 29690 tcp6 0 0 :::29690 :::* LISTEN 16817/ns-slapd # ldapsearch -x -h difda.temp -s base -b "" "objectclass=*" # extended LDIF # # LDAPv3 # base <> with scope baseObject # filter: objectclass=* # requesting: ALL dn: objectClass: top defaultnamingcontext: dc=difda,dc=temp dataversion: 020180402172520 netscapemdsuffix: cn=ldap://dc=difda,dc=temp:389 # search result search: 2 result: 0 Success # numResponses: 2 # numEntries: 1 Not sure if this is correct because it is looking at port 389 which had been assigned in the first run of setup-ds.pl. Restarted the service and ran that command again but it still came back with port 389. In general the tests look fine but the false starts give cause for concern. Might have to clear the slate and start again.
Sorry, wrong bug. Transferring the report...