[Bug 197004] [net/openldap24-server] Unable to generate SSHA256/384/512 hashes using SHA2 overlay

bugzilla-noreply at freebsd.org bugzilla-noreply at freebsd.org
Thu Jan 22 14:09:54 UTC 2015


https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=197004

            Bug ID: 197004
           Summary: [net/openldap24-server] Unable to generate
                    SSHA256/384/512 hashes using SHA2 overlay
           Product: Ports & Packages
           Version: Latest
          Hardware: Any
                OS: Any
            Status: New
          Severity: Affects Only Me
          Priority: ---
         Component: Individual Port(s)
          Assignee: freebsd-ports-bugs at FreeBSD.org
          Reporter: freebsd at jonathanprice.org

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.

-- 
You are receiving this mail because:
You are the assignee for the bug.


More information about the freebsd-ports-bugs mailing list