On a correctly functioning install of OpenLDAP with the SHA2 overlay installed (testing done from CentOS), I can run the following command: slappasswd -h '{SSHA512}' -o module-path=/usr/local/libexec/openldap -o module-load=pw-sha2 -s test {SSHA512}TSwAWmK3sv42RbAasugMPR8d7GLozXtKU00v5Jdd4ebmXBsOpt5We5HNkXxFfy5Ptaoa/KUsmTV5484NA3UmrHrOpyUVnEh9 However, upon installing OpenLDAP from ports on FreeBSD with the SHA2 option selected, running the same command gives the output shown below: slappasswd -h '{SSHA512}' -o module-path=/usr/local/libexec/openldap -o module-load=pw-sha2 -s test Password verification failed. This occurs for SSHA256, SSHA384 and SSHA512. However, SHA256, SHA384 and SHA512 all work correctly (example output below): slappasswd -h '{SHA512}' -o module-path=/usr/local/libexec/openldap -o module-load=pw-sha2 -s test {SHA512}7iaw3Ur350mqGo7jwQrpkj9hiYB3Lkc/iBml1JQODbJ6wYX4oOHV+E+IvIh/1nsUNzLDBMxfqa2Ob1f1ACio/w== I have a limited comprehension of C, but I have attempted to narrow down the cause somewhat, findings below: -slappasswd.c The actual error is show due to lutil_passwd( &hash, &passwd, NULL, &text ) returning -1. This function checks if &hash and &passwd match, where &hash is a hashed copy of the password and &passwd is the plaintext password. I have noticed that when I print out &hash, it is always the same value (as long as the input password is the same). Ordinarily this should not be the case for a salted hash. the hash struct does contain a hash, albeit an invalid one. For example, here is the hash for the password “test”: {SSHA512}y6Qs39VYq1w6X1cjOFv7NXoS/QZ7MeB+zklDMCdwe5+dr9lq9vK9u1tLEtkkC/BbgFNm4yvmifwg/GUnLJXJRwwAAABAAAAA Perhaps also of interest, is that no matter what you enter for a password to be hashed, it always ends in AAABAAAA. My best guess would be this is where it’s meant to be placing the salt (I know very little about how salts are stored, apologies if this is completely wrong). Working backwards, it appears that the execution is going wrong with the previous statement, lutil_passwd_hash( &passwd, scheme, &hash, &text ) Whilst this returns 0, it is not setting hash correctly. This function exists in libraries/liblutil/passwd.c. It seems to just forward the details on to the correct hash function for the chosen scheme, which in this case would be hash_ssha512 in contrib/slapd-modules/passwd/sha2/slapd-sha2.c This appears to be the function where everything goes wrong, but I don’t have a great understanding of what it’s doing here. After this function has been executed, slappasswd.c runs lutil_passwd() (the function that returns -1). This function in turn runs chk_ssha512. This function returns -1 if the result of a memcmp() is non-zero. It should be returning 0 but is instead returning non-zero values (meaning the values are not equal). I have confirmed that if I produce a non-salted SHA (such as {SHA512}) the call to memcmp() returns 0. Summary: The appears to be an issue with the execution of the hash_ssha(256/384/512) functions in contrib/slapd-modules/passwd/sha2/slapd-sha2.c which causes the SHA2 overlay to produce incorrect results.
I should have noted that all testing was carried out on: FreeBSD hostname 10.1-RELEASE FreeBSD 10.1-RELEASE #0 r274401: Tue Nov 11 21:02:49 UTC 2014 root@releng1.nyi.freebsd.org:/usr/obj/usr/src/sys/GENERIC amd64 Please contact me if you require any further information / testing.
Further to my original findings, I have noticed an important factor. The SHA2 module performs correctly under FreeBSD 9.2-RELEASE (so presumably the entire 9.x family), but does NOT work under FreeBSD 10.1. I shall test it on FreeBSD 10.0 and 9.3 to confirm that it is definitely a breakage going between 9.x and 10.x.
Thanks for your submission Jonathan. For future issues, please use the following format for the title: category/port: Summary Aside from being aesthetically more pleasing and easier to read, in this case the [ ] wrapping the category/port prevented our auto-assigner from automatically assigning the issue :) I'll create a separate issue to fix the auto-assigner
I have now tested the following versions: 8.4-RELEASE: Works 9.2-RELEASE: Works 9.3-RELEASE: Works 10.0-RELEASE: Broken 10.1-RELEASE: Broken I imagine at this point it's fairly safe to assume the issue is with 9.x->10.x. And thank-you to Kubilay for fixing my title. I had put the square brackets in as I recall seeing them frequently when using GNATS, but it's nice to know there's an official layout.
A commit references this bug: Author: delphij Date: Wed May 27 22:08:40 UTC 2015 New revision: 387682 URL: https://svnweb.freebsd.org/changeset/ports/387682 Log: Add a patch to resolve symbol conflict between SHA2 module with OpenSSL's SHA2 implementation. Without this, e.g. SSHA512 scheme would result in a crash due to stack corruption, which is a result of different SHA512 context size in the contributed SHA2 implementation and the OpenSSL one, plus the allocation is on stack. PR: 197004 MFH: 2015Q2 Changes: head/net/openldap24-server/files/patch-contrib_slapd-modules_passwd_sha2_sha2.h
A commit references this bug: Author: delphij Date: Wed May 27 22:09:16 UTC 2015 New revision: 387683 URL: https://svnweb.freebsd.org/changeset/ports/387683 Log: MFH: r387682 Add a patch to resolve symbol conflict between SHA2 module with OpenSSL's SHA2 implementation. Without this, e.g. SSHA512 scheme would result in a crash due to stack corruption, which is a result of different SHA512 context size in the contributed SHA2 implementation and the OpenSSL one, plus the allocation is on stack. PR: 197004 Approved by: ports-secteam Changes: _U branches/2015Q2/ branches/2015Q2/net/openldap24-server/files/patch-contrib_slapd-modules_passwd_sha2_sha2.h
This should have been fixed now, thanks for reporting.