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

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

Package updated to version 1.3.5.19 for cauldron and patched packages uploaded for Mageia 5 and 6.

Advisory:
========================

Updated 389-ds-base package fixes security vulnerability:

The directory server password lockout policy prevents binds from operating once a threshold of failed passwords has been met. During this lockout, if you bind with a successful password, a different error code is returned. This means that an attacker has no ratelimit or penalty during an account lock, and can continue to attempt passwords via bruteforce, using the change in return code to ascertain a sucessful password auth (CVE-2017-7751).


References:
https://cve.mitre.org/cgi-bin/cvename.cgi?name=CVE-2017-7551
https://access.redhat.com/errata/RHSA-2017:2569
========================

Updated packages in core/updates_testing:
========================
389-ds-base1.3.4.14-1.3.mga5
lib64389-ds-base0-1.3.4.14-1.3.mga5
lib64389-ds-base-devel-1.3.4.14-1.3.mga5
389-ds-base1.3.5.17-1.1.mga5
389-ds-base-snmp-1.3.5.17-1.1.mga5
lib64389-ds-base0-1.3.5.17-1.1.mga5
lib64389-ds-base-devel-1.3.5.17-1.1.mga5

from SRPMS:
389-ds-base-1.3.4.14-1.3.mga5.src.rpm
389-ds-base-1.3.5.17-1.1.mga6.src.rpm


Testing procedures:
https://bugs.mageia.org/show_bug.cgi?id=11720#c7
https://bugs.mageia.org/show_bug.cgi?id=16928#c7

Whiteboard: MGA6TOO, MGA5TOO => MGA5TOO
CC: (none) => mrambo
Version: Cauldron => 6
Assignee: pkg-bugs => qa-bugs

Created attachment 9668 [details]
errors in dirsrv

CC: (none) => herman.viaene

NOTE in Comment 2: the llast 4 packages should be 'mga6'.
~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
Testing M5/64
I already had this installed, so followed the 2 similar procedures:
 https://bugs.mageia.org/show_bug.cgi?id=20138#c3 ->
 https://bugs.mageia.org/show_bug.cgi?id=16928#c7

BEFORE the update:
 389-ds-base-1.3.4.14-1.2.mga5
 lib64389-ds-base0-1.3.4.14-1.2.mga5

# systemctl start 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 Sul 2017-09-10 15:01:51 CEST; 26s ago
  Process: 20731 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: 20732 (ns-slapd)
   CGroup: /system.slice/system-dirsrv.slice/dirsrv@localhost.service
           └─20732 /usr/sbin/ns-slapd -D /etc/dirsrv/slapd-localhost -i /var/...

# netstat -pant | grep 389
tcp6       0      0 :::389                  :::*                    LISTEN      20732/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: 020170910130151
netscapemdsuffix: cn=ldap://dc=localhost,dc=localdomain:389

# search result
search: 2
result: 0 Success

# numResponses: 2
# numEntries: 1
----------------
AFTER the update:
 389-ds-base-1.3.4.14-1.3.mga5
 lib64389-ds-base0-1.3.4.14-1.3.mga5

# systemctl restart dirsrv@localhost

# systemctl status dirsrv@localhost
showed an extra process
  Process: 21735 ExecStopPost=/bin/rm -f /var/run/dirsrv/slapd-%i.pid (code=exited, status=0/SUCCESS)
due to the restart; otherwise eqivalent to before.

# netstat -pant | grep 389
Essentially identical.

# ldapsearch -x -h localhost -s base -b ""  "objectclass=*"
Esentially identical.
------------------
Update looks fine.
Advisory uploaded, corrected CVE-id in Description.

CC: (none) => lewyssmith
Whiteboard: MGA5TOO, has_procedure => MGA5TOO, has_procedure MGA5-64-OK
Keywords: (none) => advisory

mga6  x86_64

The setup process for the server is far from straightforward.
It refused to accept the hostname, which is simply belexeuli.  And it failed on many different combinations, even localhost.domain given as an alias. It took ten attempts and more than 40 minutes work to find something that worked, by which time I was pretty well scunnered with the whole thing and ready to put my fist through the screen.  In 20 years of naming machines this is the first occasion when any software has objected.  In the end I had to place <ip> localhost.localdomain in the hosts file as a separate entry.

So, using localhost as the server name instead of belexeuli.
Following Claire's/Lewis' example, before the update:
# netstat -pant | grep 389
tcp6       0      0 :::389                  :::*                    LISTEN      15605/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: 020170910153244
netscapemdsuffix: cn=ldap://dc=localhost,dc=localdomain:389

# search result
search: 2
result: 0 Success

# numResponses: 2
# numEntries: 1

So far so good but it would be better to check the "directory server password lockout policy prevents binds from operating once a threshold of failed passwords has been met" business.  There is a PoC at https://pagure.io/389-ds-base/issue/49336 which is worth trying.

$ ldapwhoami -H ldap://localhost -x -D 'uid=testuser,dc=example,dc=com' -w

The -w was not accepted and no password prompt was issued when this was run:
#  ldapwhoami -H ldap://localhost -x -D 'uid=958,dc=localhost,dc=localdomain' 
ldap_bind: Server is unwilling to perform (53)
	additional info: Unauthenticated binds are not allowed

Looks like a little research is needed....

CC: (none) => tarazed25

@Len : I am trying this in parallel M6/64 if only to get the thing installed.

@Lewis : OK

M6/64

1. https://bugs.mageia.org/show_bug.cgi?id=16928#c4
/etc/hosts =
127.0.0.1   localhost.localdomain localhost
::1         localhost

2. Installed: 389-ds-base-1.3.5.17-1.mga6
which pulled in 25 other pkgs including: lib64389-ds-base0-1.3.5.17-1.mga6

3. # setup-ds.pl
2 NOTICEs, 2 WARNINGs, not important.
Chose Express setup, ->
Directory Manager DN [cn=Directory Manager]: 
Password: 
Password (confirm): 
Your new DS instance 'localhost' was successfully created.
Exiting . . .
Log file is '/tmp/setup6MhlHn.log'

BEFORE update:
Then copied Comment 4:

# 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 Sul 2017-09-10 19:35:13 CEST; 3min 4s ago
...
Med 10 19:35:12 localhost.localdomain systemd[1]: Starting 389 Directory Server 
Med 10 19:35:13 localhost.localdomain ns-slapd[15403]: [10/Sep/2017:19:35:13.111
Med 10 19:35:13 localhost.localdomain ns-slapd[15403]: [10/Sep/2017:19:35:13.233
Med 10 19:35:13 localhost.localdomain ns-slapd[15403]: [10/Sep/2017:19:35:13.890
Med 10 19:35:13 localhost.localdomain systemd[1]: Started 389 Directory Server l

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

# ldapsearch -x -h localhost -s base -b ""  "objectclass=*"
O/P exactly as in comment 4.

So all this looks in order for starters.
----------------------------------------
AFTER update:
 389-ds-base-1.3.5.17-1.1.mga6
 lib64389-ds-base0-1.3.5.17-1.1.mga6

# systemctl restart dirsrv@localhost

# systemctl status dirsrv@localhost
Essentially the same as before, but with just 2 (rather than 3)
 localhost.localdomain ns-slapd
lines; and no extra process for the restart.

# netstat -pant | grep 389
Essentially identical O/P.

# ldapsearch -x -h localhost -s base -b ""  "objectclass=*"
Essentially identical O/P.

So this update looks good.

Whiteboard: MGA5TOO, has_procedure MGA5-64-OK => MGA5TOO, has_procedure MGA5-64-OK MGA6-64-OK

Re PoC:

Tried several times with various combinations:-

$ ldapwhoami -H ldap://localhost -x -D 'uid=lcl,dc=localhost,dc=localdomain' -w <dirsrv password>
ldap_bind: Invalid credentials (49)
$ ldapwhoami -H ldap://localhost -x -D 'uid=958,dc=localhost,dc=localdomain' -w <dirsrv password>
ldap_bind: Invalid credentials (49)
$ ldapwhoami -H ldap://localhost -x -D 'uid=lcl,dc=localhost,dc=localdomain' -w <user password>
ldap_bind: Invalid credentials (49)
$ ldapwhoami -H ldap://localhost -x -D 'uid=dirsrv,dc=localhost,dc=localdomain' -w <dirsrv password>
ldap_bind: Invalid credentials (49)

The 'ldap_bind: Invalid credentials (49)' message indicates that the password lockout is already in effect but since I don't actually know what strings should be placed in the fields above, ter is little possibility of triggering the 'Constraint violation (19)' message.

Better leave it there, unless somebody has a deeper knowledge of the parameters.

PoC again:

$ id dirsrv
uid=969(dirsrv) gid=958(dirsrv) groups=958(dirsrv)

It was the gid being used above, so:

$ ldapwhoami -H ldap://localhost -x -D 'uid=968,dc=localhost,dc=localdomain' -w <dirsrv password>
ldap_bind: Invalid credentials (49)

Hmm!

Slip of the finger there bu no matter - it makes no difference.

One last try as root.

Last line of passwd file:
dirsrv:x:969:958:system user for 389-ds-base:/var/lib/dirsrv:/sbin/nologin

# ldapwhoami -H ldap://localhost -x -D 'uid=969,dc=localhost,dc=localdomain' -w <dirsrv password>
ldap_bind: Invalid credentials (49)

@Len
You were right to persue the PoC (thanks for finding it, I overlooked it). I was not sure whether you were trying it out before &/or after the update. Nor what your verdict on the 3 given commands was. BTW, did you do:
 # systemctl start dirsrv@localhost

It looks to me as if you need a local LDAP server set up; with a valid user registered. Do you agree? Do you have?
I take it the first command is the normal, correct case; the control. Can we demonstrate that? It seems to be the starting point for the next two:
- Try several times with an invalid password to create the lockout (49).
- Re-try with a valid password (19).
I think the last is meant to fail as shown (= bug) *before* the update; and succeed after it. The PoC wording implies that once the lockout exists, you "can continue to attempt passwords via bruteforce"; which makes sense to me if the attacker looks for error (19) => valid password. I suppose the correct idea is to accept valid binds regardless of lockout.

@Lewis
Yes I did start the server and the tests were before the update.  All my faffing about probably caused the password limit to be exceeded but the lockout message never appeared because I did not know the correct credentials and still do not.
It is meant to fail a few times and then return a different message after the lockout when the correct credentials are entered - I think.  It is unclear from the text but I would assume that the 'constraint violation' message would appear after the patch has been applied.  Maybe I should try the update. 

I am assuming that dirsrv is the valid user - it appears in the password file.  And I definitely used the correct password - the one created at setup time.

M6/64 continued to try the PoC.
I cannot even start the service now.

# systemctl start dirsrv@localhost
Job for dirsrv@localhost.service failed because the control process exited with error code.
See "systemctl status dirsrv@localhost.service" and "journalctl -xe" for details

# journalctl -xel
Med 12 10:08:42 localhost.localdomain systemd[1]: Starting 389 Directory Server 
-- Subject: Unit dirsrv@localhost.service has begun start-up
-- Defined-By: systemd
-- Support: http://lists.freedesktop.org/mailman/listinfo/systemd-devel
-- Unit dirsrv@localhost.service has begun starting up.
Med 12 10:08:43 localhost.localdomain ns-slapd[13845]: [12/Sep/2017:10:08:43.388
... +0200] Unable to access nsslapd-rundir: No such file or directoryMed 12 10:08:43 localhost.localdomain ns-slapd[13845]: [12/Sep/2017:10:08:43.434
... +0200] Ensure that user "dirsrv" has read and write permissions on /var/run/dirsrv
422651 +0200] Shutting down.
Med 12 10:08:43 localhost.localdomain ns-slapd[13845]: [12/Sep/2017:10:08:43.492
Med 12 10:08:43 localhost.localdomain systemd[1]: dirsrv@localhost.service: Main
Med 12 10:08:43 localhost.localdomain systemd[1]: Failed to start 389 Directory 
-- Subject: Unit dirsrv@localhost.service has failed
-- Defined-By: systemd
-- Support: http://lists.freedesktop.org/mailman/listinfo/systemd-devel
-- Unit dirsrv@localhost.service has failed.
-- The result is failed.
Med 12 10:08:43 localhost.localdomain systemd[1]: dirsrv@localhost.service:...
...Unit entered failed state.
Med 12 10:08:43 localhost.localdomain systemd[1]: dirsrv@localhost.service:...
...Failed with result 'exit-code'.

# ls -l /var/run/dirsrv
ls: cannot access '/var/run/dirsrv': No such file or directory

@lewis
This is getting strange.
dirsrv@localhost was already running here.  systemctl status showed that things were fine.
# systemctl start dirsrv@localhost 
made no comment but status showed that it had restarted and was running fine.
Stopping and starting the service also worked after that.
# ls -l /var/run/dirsrv
total 8
-rw-r--r-- 1 dirsrv dirsrv    5 Sep 12 11:36 slapd-localhost.pid
-rw-r--r-- 1 dirsrv dirsrv 2088 Sep 12 11:36 slapd-localhost.stats

Perhaps the perl script needs to be run again.  ?
I was thinking of uninstalling and trying the whole thing again to test the PoC.

MGA6-32 on Asus A6000VM MATE
No installation issues.
The fog is even getting thicker. I get as root at CLI:
# setup-ds.pl 

==============================================================================
This program will set up the 389 Directory Server.

It is recommended that you have "root" privilege to set up the software.
Tips for using this  program:
  - Press "Enter" to choose the default and go to the next screen
  - Type "Control-B" or the word "back" then "Enter" to go back to the previous screen
  - Type "Control-C" to cancel the setup program

Would you like to continue with set up? [yes]: 

==============================================================================
Your system has been scanned for potential problems, missing patches,
etc.  The following output is a report of the items found that need to
be addressed before running this software in a production
environment.

389 Directory Server system tuning analysis version 14-JULY-2016.

NOTICE : System is i686-unknown-linux4.9.43-desktop-1.mga6 (1 processor).

ERROR: This system does not support CMPXCHG16B instruction (cpuflag cx16).
       nsslapd-enable-nunc-stans must be set to "off" on this system. 
       In a future release of Directory Server this platform will NOT be supported.
and some more.
I googled on nsslapd-enable-nunc-stans and found in https://bugzilla.redhat.com/show_bug.cgi?id=1278729 :
# tail -n1 /etc/profile
export MAX_THREADS=100

nsslapd-threadnumber: 30
nsslapd-enable-nunc-stans: off

So I added this last line to /etc/profile and rebooted. And of course got the error that nsslapd-enable-nunc-stans was unknown. From other searches I got the impression that this expression is a compile-time item, so trying to manipulate it now seems a no-go. That makes me feel this package cannot run at all on this machine.

(In reply to Herman Viaene from comment #17)
> MGA6-32 on Asus A6000VM MATE
> ERROR: This system does not support CMPXCHG16B instruction (cpuflag cx16).
>        nsslapd-enable-nunc-stans must be set to "off" on this system. 
>        In a future release of Directory Server this platform will NOT be
>        supported.
It looks as if the processor does not have certain required instructions,
> I got the impression that this expression is a compile-time item
Looks sensible; and your suspicion:
> That makes me feel this package cannot run at all on this machine.
is probably right. Thanks for trying.

Further to my comment 15...
I decided to back to square one, and re-install this.
 # urpme 389-ds-base lib64389-ds-base0
[left a lot of orphans]
First from Updates Testing:
389-ds-base-1.3.5.17-1.1.mga6, lib64389-ds-base0-1.3.5.17-1.1.mga6
 # setup-ds.pl
Error: the server already exists at '/etc/dirsrv/slapd-localhost'
Please remove it first if you really want to recreate it,
 # rm -rf /etc/dirsrv/slapd-localhost/
none of which is provided by the package, so presume created on the fly. But it suggests that removing the pkg is not clean.
 # setup-ds.pl
...
 You will also be prompted for the password for this user.  The password must
 be at least 8 characters long, and contain no spaces.
 Directory Manager DN [cn=Directory Manager]: <password>
 The input '<password>' is not a valid DN.  Please choose another one.
I used the same one as for the original successful installation. Curiously, the password was echoed, which is suspicious.
I never got further. Uninstalled it again, removed /etc/dirsrv/ /var/lib/dirsrv/
Re-installed from issued repos (before update) and *always* hit this problem.
Have to give up.

@Len: do you think we should pass this without the PoC test?

@ Lewis
While searching I found two things:
1. the package has a removeXXXXX command which should .... well remove a database.
2. there is also a config file for dirsrv in /etc/sysconfig.
But neithe of those two brought me any nearer to configureing a neww setup , maybe you have more luck.

@Lewis
Yes, perhaps we should pass it as is.  I had been thinking of repeating the whole procedure but you and Herman have tried that.  Iwas never confident that the system was properly installed because it never at any stage accepted the password I set up.  And we have foregone PoC tests in the past.  It is good to run them successfully but in this case the system is making things awkward for us.  I vote send it on its way.

An update for this issue has been pushed to the Mageia Updates repository.

http://advisories.mageia.org/MGASA-2017-0340.html

Resolution: (none) => FIXED
Status: NEW => RESOLVED