Bug 22710

Assigning to all packagers collectively, since there is no registered maintainer for this package.

Assignee: bugsquad => pkg-bugs
CC: (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-1054
Assignee: pkg-bugs => qa-bugs
Version: Cauldron => 6
CC: (none) => smelror
Whiteboard: 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) => tarazed25
Whiteboard: (none) => MGA6-64-OK

And be validated!

Keywords: (none) => validated_update
CC: (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 => RESOLVED
Resolution: (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...