Bug 1517788

Summary: password policy: minimum token length fails when the token lenght is equal to attribute length.
Product: Red Hat Enterprise Linux 7 Reporter: German Parente <gparente>
Component: 389-ds-baseAssignee: mreynolds
Status: CLOSED ERRATA QA Contact: Viktor Ashirov <vashirov>
Severity: unspecified Docs Contact: Marc Muehlfeld <mmuehlfe>
Priority: unspecified    
Version: 7.4CC: aadhikar, enewland, gparente, mreynolds, nkinder, rmeggins
Target Milestone: rc   
Target Release: ---   
Hardware: Unspecified   
OS: Unspecified   
Whiteboard:
Fixed In Version: 389-ds-base-1.3.7.5-12 Doc Type: Bug Fix
Doc Text:
The Directory Server trivial word check password policy now works as expected Previously, when you set a "userPassword" attribute to exactly the same value as an attribute restricted by the "passwordTokenMin" setting with the same length, Directory Server incorrectly allowed the password update operation. With this update, the trivial word check password policy feature now correctly verifies the entire user attribute value as a whole, and the described problem no longer occurs.
Story Points: ---
Clone Of: Environment:
Last Closed: 2018-04-10 14:22:34 UTC Type: Bug
Regression: --- Mount Type: ---
Documentation: --- CRM:
Verified Versions: Category: ---
oVirt Team: --- RHEL 7.3 requirements from Atomic Host:
Cloudforms Team: ---

Description German Parente 2017-11-27 13:19:02 UTC
Description of problem:

the function check_trivial_words is failing to recongnize a token that is exactly same size as the token length.

Example:

dn: uid=Dord,ou=People,dc=parente,dc=local
sn: David
objectClass: top
objectClass: account
objectClass: posixaccount
objectClass: inetOrgPerson
objectClass: organizationalPerson
objectClass: person
uid: Dord
cn: David
loginShell: /bin/bash
homeDirectory: /home/dorda
uidNumber: 501003
gidNumber: 510003

passwordMinTokenLength: 4

ldapmodify -D "uid=Dord,ou=People,dc=parente,dc=local" -w secret12
dn: uid=Dord,ou=People,dc=parente,dc=local
changetype: modify
replace: userpassword
userPassword: dord

modifying entry "uid=Dord,ou=People,dc=parente,dc=local"



Actual results

the password including a token of 4 length is accepted (it's the exact length of the attribute).

Version-Release number of selected component (if applicable): 389-ds-base-1.3.6.1-21


How reproducible: always


Actual results:

password is not refused.


Expected results:

password refused when the token length is same length than the attribute.


Additional info:


After some debugging, the function:

check_trivial_words calls

ldap_utf8prevn(sp, ep, toklen);

This function returns NULL when the token length is same length than the attribute value in "sp".

IMHO, this should be the fix:

char
ldap_utf8prevn(char s, char from, int n)
{
char prev = from;
if (!s || !from || (s > from)) {
return NULL;
}
for (; n > 0; --n) {
prev = ldap_utf8prev(prev);
if ((prev <= s) && (n > 0)) { <============= should be (prev < s)
return NULL;
}
}
return prev;
}

For instance, in the previous example,

ldap_utf8prevn("dord", char *from,4)

will loop to find the postfix d, rd, ord, and will return NULL for dord.

So check_trivial_words will fail to refuse the password.

Comment 2 mreynolds 2018-01-04 17:29:47 UTC
Investigating, but German you told me in a meeting that would found another issue when the token length is set higher than 6 (or something like that).  Can you elaborate on this other issue you found?

Comment 4 mreynolds 2018-01-05 15:33:13 UTC
Upstream ticket:
https://pagure.io/389-ds-base/issue/49524

Comment 5 mreynolds 2018-01-08 16:42:10 UTC
Fixed upstream

Comment 7 Akshay Adhikari 2018-02-13 12:35:43 UTC
============================================================================ test session starts ============================================================================
platform linux -- Python 3.6.3, pytest-3.4.0, py-1.5.2, pluggy-0.6.0 -- /opt/rh/rh-python36/root/usr/bin/python3
cachedir: .pytest_cache
metadata: {'Python': '3.6.3', 'Platform': 'Linux-3.10.0-845.el7.x86_64-x86_64-with-redhat-7.5-Maipo', 'Packages': {'pytest': '3.4.0', 'py': '1.5.2', 'pluggy': '0.6.0'}, 'Plugins': {'metadata': '1.5.1', 'html': '1.16.1'}}
389-ds-base: 1.3.7.5-18.el7
nss: 3.34.0-4.el7
nspr: 4.17.0-1.el7
openldap: 2.4.44-13.el7
svrcore: 4.1.3-2.el7

rootdir: /mnt/tests/rhds/tests/upstream/ds/dirsrvtests/tests/suites/password, inifile:
plugins: metadata-1.5.1, html-1.16.1
collected 1 item                                                                                                                                                            

pwdPolicy_token_test.py::test_token_lengths OK group dirsrv exists
OK user dirsrv exists
INFO:lib389.topologies:Instance with parameters {'ldap-port': 38901, 'ldap-secureport': 63601, 'server-id': 'standalone1', 'suffix': 'dc=example,dc=com'} was created.
INFO:dirsrvtests.tests.suites.password.pwdPolicy_token_test:Testing password len 4 token (test)
INFO:dirsrvtests.tests.suites.password.pwdPolicy_token_test:Password correctly rejected: {'desc': 'Constraint violation', 'info': 'invalid password syntax - password based off of user entry'}
INFO:dirsrvtests.tests.suites.password.pwdPolicy_token_test:Testing password len 6 token (test_u)
INFO:dirsrvtests.tests.suites.password.pwdPolicy_token_test:Password correctly rejected: {'desc': 'Constraint violation', 'info': 'invalid password syntax - password based off of user entry'}
INFO:dirsrvtests.tests.suites.password.pwdPolicy_token_test:Testing password len 10 token (test_user1)
INFO:dirsrvtests.tests.suites.password.pwdPolicy_token_test:Password correctly rejected: {'desc': 'Constraint violation', 'info': 'invalid password syntax - password based off of user entry'}
PASSEDInstance slapd-standalone1 removed.


========================================================================= 1 passed in 12.40 seconds =========================================================================

Comment 12 errata-xmlrpc 2018-04-10 14:22:34 UTC
Since the problem described in this bug report should be
resolved in a recent advisory, it has been closed with a
resolution of ERRATA.

For information on the advisory, and where to find the updated
files, follow the link below.

If the solution does not work for you, open a new bug report.

https://access.redhat.com/errata/RHBA-2018:0811