From owner-freebsd-ports-bugs@FreeBSD.ORG Thu Jan 22 14:09:54 2015 Return-Path: Delivered-To: freebsd-ports-bugs@FreeBSD.org Received: from mx1.freebsd.org (mx1.freebsd.org [8.8.178.115]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by hub.freebsd.org (Postfix) with ESMTPS id 236D774F for ; Thu, 22 Jan 2015 14:09:54 +0000 (UTC) Received: from kenobi.freebsd.org (kenobi.freebsd.org [IPv6:2001:1900:2254:206a::16:76]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (Client did not present a certificate) by mx1.freebsd.org (Postfix) with ESMTPS id 0A3B39CA for ; Thu, 22 Jan 2015 14:09:54 +0000 (UTC) Received: from bugs.freebsd.org ([127.0.1.118]) by kenobi.freebsd.org (8.14.9/8.14.9) with ESMTP id t0ME9rio098391 for ; Thu, 22 Jan 2015 14:09:53 GMT (envelope-from bugzilla-noreply@freebsd.org) From: bugzilla-noreply@freebsd.org To: freebsd-ports-bugs@FreeBSD.org Subject: [Bug 197004] [net/openldap24-server] Unable to generate SSHA256/384/512 hashes using SHA2 overlay Date: Thu, 22 Jan 2015 14:09:54 +0000 X-Bugzilla-Reason: AssignedTo X-Bugzilla-Type: new X-Bugzilla-Watch-Reason: None X-Bugzilla-Product: Ports & Packages X-Bugzilla-Component: Individual Port(s) X-Bugzilla-Version: Latest X-Bugzilla-Keywords: X-Bugzilla-Severity: Affects Only Me X-Bugzilla-Who: freebsd@jonathanprice.org X-Bugzilla-Status: New X-Bugzilla-Priority: --- X-Bugzilla-Assigned-To: freebsd-ports-bugs@FreeBSD.org X-Bugzilla-Target-Milestone: --- X-Bugzilla-Flags: X-Bugzilla-Changed-Fields: bug_id short_desc product version rep_platform op_sys bug_status bug_severity priority component assigned_to reporter Message-ID: Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: quoted-printable X-Bugzilla-URL: https://bugs.freebsd.org/bugzilla/ Auto-Submitted: auto-generated MIME-Version: 1.0 X-BeenThere: freebsd-ports-bugs@freebsd.org X-Mailman-Version: 2.1.18-1 Precedence: list List-Id: Ports bug reports List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 22 Jan 2015 14:09:54 -0000 https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=3D197004 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@FreeBSD.org Reporter: freebsd@jonathanprice.org On a correctly functioning install of OpenLDAP with the SHA2 overlay instal= led (testing done from CentOS), I can run the following command: slappasswd -h '{SSHA512}' -o module-path=3D/usr/local/libexec/openldap -o module-load=3Dpw-sha2 -s test {SSHA512}TSwAWmK3sv42RbAasugMPR8d7GLozXtKU00v5Jdd4ebmXBsOpt5We5HNkXxFfy5Pta= oa/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=3D/usr/local/libexec/openldap -o module-load=3Dpw-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=3D/usr/local/libexec/openldap -o module-load=3Dpw-sha2 -s test {SHA512}7iaw3Ur350mqGo7jwQrpkj9hiYB3Lkc/iBml1JQODbJ6wYX4oOHV+E+IvIh/1nsUNzL= DBMxfqa2Ob1f1ACio/w=3D=3D 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, he= re is the hash for the password =E2=80=9Ctest=E2=80=9D: {SSHA512}y6Qs39VYq1w6X1cjOFv7NXoS/QZ7MeB+zklDMCdwe5+dr9lq9vK9u1tLEtkkC/BbgF= Nm4yvmifwg/GUnLJXJRwwAAABAAAAA Perhaps also of interest, is that no matter what you enter for a password t= o be hashed, it always ends in AAABAAAA. My best guess would be this is where it= =E2=80=99s 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,=20 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 forwa= rd 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=E2= =80=99t have a great understanding of what it=E2=80=99s 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. --=20 You are receiving this mail because: You are the assignee for the bug.=