openldap-bugs

openldap-bugs@openldap.org

1 participants
21001 discussions

(ITS#9143) Segfault in libcrypto.so.1.1
by s.peillon＠caenlamer.fr 14 Dec '19

14 Dec '19

Full_Name: St.phane P. Version: 2.4.48 OS: Ubuntu 18.04 URL: ftp://ftp.openldap.org/incoming/ Submission from: (NULL) (90.63.253.253) Hello, I just upgraded the OpenLDAP engine to 2.4.48. Following this migration, I observed errors related to the libcrypto.so.1.1 library in the syslogs when executing commands such as: /usr/local/openldap/sbin/slapcat -F /usr/local/openldap/etc/openldap/slapd.d -F /usr/local/openldap/etc/openldap/slapd.d -b cn = config -a ' (| (objectclass = olcBdbConfig) (objectclass = olcHdbConfig) (objectclass = olcMdbConfig)) ' The errors are: kernel: [110775.944931] slapcat [2659]: segfault at 60 ip 00007fa1afc98300 sp 00007fff98c66b20 error 4 in libcrypto.so.1.1 [7fa1afaa2000 + 29b000] The linux version is: Linux XXXXXXXX 4.15.0-72-generic-81-Ubuntu SMP Tue Nov 26 12:20:02 UTC 2019 x86_64 x86_64 x86_64 GNU / Linux Can you tell me what to modify to correct this error? thank you in advance for your help ! Stephane

1 0

(ITS#9142) LDAP Connection Close
by pasumarthivijaykumar＠gmail.com 14 Dec '19

14 Dec '19

Full_Name: Vijay Kumar Version: 2.4.48 OS: Debian Linux URL: ftp://ftp.openldap.org/incoming/ Submission from: (NULL) (124.123.75.91) Hi, i have facing a "connection close" issue with openldap image which is available at https://github.com/osixia/docker-openldap details of as mentioned below, 5df4c06f conn=1022 op=2456 SEARCH RESULT tag=101 err=0 nentries=1 text= 5df4c06f conn=1022 op=2457 SRCH base="cn=com__cws_runtime_types_teamdevelopment_SCMAdapter.SCMAdapterBinding,cn= CWS Bootstrap Helper,cn=,cn=defaultInst,o=trialorg.local" scope=0 deref=0 filter="(objectClass=*)" 5df4c06f conn=1022 op=2457 SRCH attr=* entryUUID 5df4c06f conn=1022 op=2457 SEARCH RESULT tag=101 err=32 nentries=0 text= 5df4c06f conn=1022 op=2458 ADD dn="cn=com__cws_runtime_types_teamdevelopment_SCMAdapter.SCMAdapterBinding,cn= CWS Bootstrap Helper,cn=,cn=defaultInst,o=trialorg.local" 5df4c06f conn=1022 op=2458 RESULT tag=105 err=0 text= 5df4c06f conn=1022 op=2459 SRCH base="cn=determineIncorporateChangeSet,cn=com__cws_runtime_types_teamdevelopment_SCMAdapter.SCMAdapterBinding,cn= CWS Bootstrap Helper,cn=,cn=defaultInst,o=trialorg.local" scope=0 deref=0 filter="(objectClass=*)" 5df4c06f conn=1022 op=2459 SRCH attr=* entryUUID 5df4c06f conn=1022 op=2459 SEARCH RESULT tag=101 err=32 nentries=0 text= 5df4c06f conn=1022 fd=18 closed (connection lost) 5df4c070 conn=1068 fd=18 ACCEPT from IP=192.168.240.4:50007 (IP=0.0.0.0:636) TLS: gnutls_certificate_verify_peers2 failed -49 5df4c070 conn=1068 fd=18 TLS established tls_ssf=256 ssf=256 5df4c070 conn=1068 op=0 BIND dn="cn=Directory Manager,o=trialorg.local" method=128 5df4c070 conn=1068 op=0 BIND dn="cn=Directory Manager,o=trialorg.local" mech=SIMPLE ssf=0 5df4c070 conn=1068 op=0 RESULT tag=97 err=0 text= 5df4c073 conn=1069 fd=20 ACCEPT from IP=127.0.0.1:59438 (IP=0.0.0.0:389) 5df4c073 conn=1069 op=0 BIND dn="cn=admin,dc=trialorg,dc=local" method=128 5df4c073 conn=1069 op=0 BIND dn="cn=admin,dc=trialorg,dc=local" mech=SIMPLE ssf=0 5df4c073 conn=1069 op=0 RESULT tag=97 err=0 text= Can any one please let us know how to solve this connection issue?

1 0

Re: (ITS#9137) slappasswd generate wrong SSHA from file
by antoine.tran＠thales-services.fr 13 Dec '19

13 Dec '19

Hi, Thank you!! I was fooled when I checked the content with vi. Sorry for the disturbance, I hope it will help others. Yours sincerely, Antoine On 13/12/2019 04:29, Howard Chu wrote: > Antoine Tran wrote: >> On 12/12/2019 14:02, Howard Chu wrote: >>> antoine.tran(a)thales-services.fr wrote: >>>> Full_Name: Antoine TRAN >>>> Version: openldap-servers-2.4.44-21.el7_6.x86_64 >>>> OS: CentOS Linux release 7.7.1908 (Core) >>>> URL: ftp://ftp.openldap.org/incoming/ >>>> Submission from: (NULL) (213.190.88.94) >>>> >>>> >>>> I use slappasswd to generate SSHA password. The issue is it behavior is >>>> different whether I submit the password - in stdin or in command-line '-s' - and >>>> from a secret file '-T'. Command: >>>> slappasswd -h {SSHA} >>>> => write 'd' twice as password >>>> slappasswd -h {SSHA} -s d >>>> >>>> provides working SSHA. >>>> >>>> But: >>>> echo d >/run/secrets/rootpw >>>> slappasswd -h {SSHA} -T /run/secrets/rootpw >>>> provides a valid SSHA, but that does not match the password. >>>> >>>> My multiple test are done by replacing rootpw in /etc/openldap/slapd.conf, >>>> regenerating with: >>>> systemctl stop slapd >>>> sed -i -e "s,rootpw .*\$,rootpw ${ROOTPW_HASH},g" /etc/openldap/slapd.conf >>>> slapcat -n 0 -f /etc/openldap/slapd.conf -F /etc/openldap/slapd.d >>>> systemctl start slapd >>>> ldapsearch -D "${ROOTDN}" -w "${ROOTPW}" >>>> >>>> The content of the secret file can be "d" or "d\n", it does not make a >>>> difference. Also, if I change the schema from SSHA to just a fixed salt, the >>>> '-T' seems to work as expected: >>>> (a) slappasswd -c 123 >>>> => write d twice >>>> (b) slappasswd -c 123 -s 123 >>>> (c) slappasswd -c 123 -T /run/secrets/rootpw >>>> >>>> (a), (b) and (c) gives the exact same hash. But I cannot put a fixed salt and >>>> use SSHA, slappasswd prevents me from that, with an error schema already >>>> provided. >>> Unable to reproduce, SSHA works fine here. >>> >>> Obviously you can't use a fixed salt with SSHA, that's the point of its salt is to >>> be random and different every time. >> I wanted to override the salt as a test, to check if we have the same output with a file and in command-line. But I found another way to test. >>> When using a password in a file you must ensure the trailing '\n' is omitted. This >>> is already documented in the manpage. >> I did read and checked this point. I have written that I did not have a newline. But here is a simple and reproducible test, that took me some long time. In a >> Linux machine with internet, just copy paste this: >> >> docker run --name slappasswd --rm -ti centos:7 bash >> >> yum install openldap-servers -y >> >> cat <<EOF >/makeSecret.py >> import os >> import sys >> import hashlib >> from base64 import urlsafe_b64encode as encode >> from base64 import urlsafe_b64decode as decode >> >> def makeSecret(password): >> salt = os.urandom(4) >> h = hashlib.sha1(password) >> h.update(salt) >> return "{SSHA}" + encode(h.digest() + salt) >> >> if __name__ == '__main__': >> print(makeSecret(sys.argv[1])) >> EOF >> >> cat <<EOF >/checkPassword.py >> import os >> import sys >> import hashlib >> from base64 import urlsafe_b64encode as encode >> from base64 import urlsafe_b64decode as decode >> >> def checkPassword(challenge_password, password): >> challenge_bytes = decode(challenge_password[6:]) >> digest = challenge_bytes[:20] >> salt = challenge_bytes[20:] >> hr = hashlib.sha1(password) >> hr.update(salt) >> return digest == hr.digest() >> >> if __name__ == '__main__': >> print(checkPassword(sys.argv[1], sys.argv[2])) >> EOF >> >> python /checkPassword.py $(python /makeSecret.py d) d >> >> python /checkPassword.py $(slappasswd -s d) d >> >> mkdir -p /run/secrets/ >> echo d>/run/secrets/rootpw >> python /checkPassword.py $(slappasswd -T /run/secrets/rootpw) d >> echo Begin-$(cat /run/secrets/rootpw)-End >> # => shows no newline: >> #Begin-d-End >> >> It will show you that all hash works except the part with slappasswd -T, and I checked the newline. > I've run your steps. Your test is still invalid. Learn how to use the echo command. > > #### > [root@507ab0515ed6 /]# od -xc /run/secrets/rootpw > 0000000 0a64 > d \n > 0000002 > [root@507ab0515ed6 /]# echo -n d > /run/secrets/rootpw > [root@507ab0515ed6 /]# python /checkPassword.py $(slappasswd -T /run/secrets/rootpw) d > Warning: Password file /run/secrets/rootpw is publicly readable/writeable > True > [root@507ab0515ed6 /]# > #### > > Closing this ITS. > > >>>> I saw the same issue in another openldap mail: >>>> https://www.openldap.org/lists/openldap-software/200805/msg00060.html but no >>>> answer. >>>> >>>> >

1 0

Re: (ITS#9138)
by hyc＠symas.com 12 Dec '19

12 Dec '19

scf(a)ieee.org wrote: > Howards mentioned in another wrongly submitted issue (#9139) that > "memcmp.c isn't even referenced in the Makefile, so none of this code > is used." Here is the clarification, even if memcmp.c is not used, gcc > or other compilers' implementations of memcmp is still unsafe > (https://github.com/gcc-mirror/gcc/blob/master/libiberty/memcmp.c). > Even so, it's largely irrelevant. The default password storage scheme is a salted hash, not CLEARTEXT. The cleartext code isn't even compiled unless you explicitly configure to enable SLAPD_CLEARTEXT, and that is always disabled by default. In the normal case, where any form of hash is used, the likelihood of gaining any useful timing information from a bytewise compare of two hashes is nil. The attacker would need to know the salt and the hash algo itself would have to be vulnerable to chosen-plaintext attacks for them to be able to leverage the timing and determine match lengths. Can you actually demonstrate a password extraction attack using memcmp timing side-channel against salted SHA1? -- -- Howard Chu CTO, Symas Corp. http://www.symas.com Director, Highland Sun http://highlandsun.com/hyc/ Chief Architect, OpenLDAP http://www.openldap.org/project/

1 0

Re: (ITS#9137) slappasswd generate wrong SSHA from file
by hyc＠symas.com 12 Dec '19

12 Dec '19

Antoine Tran wrote: > On 12/12/2019 14:02, Howard Chu wrote: >> antoine.tran(a)thales-services.fr wrote: >>> Full_Name: Antoine TRAN >>> Version: openldap-servers-2.4.44-21.el7_6.x86_64 >>> OS: CentOS Linux release 7.7.1908 (Core) >>> URL: ftp://ftp.openldap.org/incoming/ >>> Submission from: (NULL) (213.190.88.94) >>> >>> >>> I use slappasswd to generate SSHA password. The issue is it behavior = is >>> different whether I submit the password - in stdin or in command-line= '-s' - and >>> from a secret file '-T'. Command: >>> slappasswd -h {SSHA} >>> =3D> write 'd' twice as password >>> slappasswd -h {SSHA} -s d >>> >>> provides working SSHA. >>> >>> But: >>> echo d >/run/secrets/rootpw >>> slappasswd -h {SSHA} -T /run/secrets/rootpw >>> provides a valid SSHA, but that does not match the password. >>> >>> My multiple test are done by replacing rootpw in /etc/openldap/slapd.= conf, >>> regenerating with: >>> systemctl stop slapd >>> sed -i -e "s,rootpw .*\$,rootpw ${ROOTPW_HASH},g" /etc/openldap/slapd= .conf >>> slapcat -n 0 -f /etc/openldap/slapd.conf -F /etc/openldap/slapd.d >>> systemctl start slapd >>> ldapsearch -D "${ROOTDN}" -w "${ROOTPW}" >>> >>> The content of the secret file can be "d" or "d\n", it does not make = a >>> difference. Also, if I change the schema from SSHA to just a fixed sa= lt, the >>> '-T' seems to work as expected: >>> (a) slappasswd -c 123 >>> =3D> write d twice >>> (b) slappasswd -c 123 -s 123 >>> (c) slappasswd -c 123 -T /run/secrets/rootpw >>> >>> (a), (b) and (c) gives the exact same hash. But I cannot put a fixed = salt and >>> use SSHA, slappasswd prevents me from that, with an error schema alre= ady >>> provided. >> Unable to reproduce, SSHA works fine here. >> >> Obviously you can't use a fixed salt with SSHA, that's the point of it= s salt is to >> be random and different every time. > I wanted to override the salt as a test, to check if we have the same o= utput with a file and in command-line. But I found another way to test. >> When using a password in a file you must ensure the trailing '\n' is o= mitted. This >> is already documented in the manpage. >=20 > I did read and checked this point. I have written that I did not have a= newline. But here is a simple and reproducible test, that took me some l= ong time. In a > Linux machine with internet, just copy paste this: >=20 > docker run --name slappasswd --rm -ti centos:7 bash >=20 > yum install openldap-servers -y >=20 > cat <<EOF >/makeSecret.py > import os > import sys > import hashlib > from base64 import urlsafe_b64encode as encode > from base64 import urlsafe_b64decode as decode >=20 > def makeSecret(password): > =C2=A0=C2=A0=C2=A0 salt =3D os.urandom(4) > =C2=A0=C2=A0=C2=A0 h =3D hashlib.sha1(password) > =C2=A0=C2=A0=C2=A0 h.update(salt) > =C2=A0=C2=A0=C2=A0 return "{SSHA}" + encode(h.digest() + salt) >=20 > if __name__ =3D=3D '__main__': > =C2=A0=C2=A0=C2=A0 print(makeSecret(sys.argv[1])) > EOF >=20 > cat <<EOF >/checkPassword.py > import os > import sys > import hashlib > from base64 import urlsafe_b64encode as encode > from base64 import urlsafe_b64decode as decode >=20 > def checkPassword(challenge_password, password): > =C2=A0=C2=A0=C2=A0 challenge_bytes =3D decode(challenge_password[6:= ]) > =C2=A0=C2=A0=C2=A0 digest =3D challenge_bytes[:20] > =C2=A0=C2=A0=C2=A0 salt =3D challenge_bytes[20:] > =C2=A0=C2=A0=C2=A0 hr =3D hashlib.sha1(password) > =C2=A0=C2=A0=C2=A0 hr.update(salt) > =C2=A0=C2=A0=C2=A0 return digest =3D=3D hr.digest() >=20 > if __name__ =3D=3D '__main__': > =C2=A0=C2=A0=C2=A0 print(checkPassword(sys.argv[1], sys.argv[2])) > EOF >=20 > python /checkPassword.py $(python /makeSecret.py d) d >=20 > python /checkPassword.py $(slappasswd -s d) d >=20 > mkdir -p /run/secrets/ > echo d>/run/secrets/rootpw > python /checkPassword.py $(slappasswd -T /run/secrets/rootpw) d > echo Begin-$(cat /run/secrets/rootpw)-End > # =3D> shows no newline: > #Begin-d-End >=20 > It will show you that all hash works except the part with slappasswd -T= , and I checked the newline. I've run your steps. Your test is still invalid. Learn how to use the ech= o command. #### [root@507ab0515ed6 /]# od -xc /run/secrets/rootpw 0000000 0a64 d \n 0000002 [root@507ab0515ed6 /]# echo -n d > /run/secrets/rootpw [root@507ab0515ed6 /]# python /checkPassword.py $(slappasswd -T /run/secr= ets/rootpw) d Warning: Password file /run/secrets/rootpw is publicly readable/writeable True [root@507ab0515ed6 /]# #### Closing this ITS. >=20 >>> I saw the same issue in another openldap mail: >>> https://www.openldap.org/lists/openldap-software/200805/msg00060.html= but no >>> answer. >>> >>> --=20 -- Howard Chu CTO, Symas Corp. http://www.symas.com Director, Highland Sun http://highlandsun.com/hyc/ Chief Architect, OpenLDAP http://www.openldap.org/project/

1 0

Re: (ITS#9137) slappasswd generate wrong SSHA from file
by antoine.tran＠thales-services.fr 12 Dec '19

12 Dec '19

This is a multi-part message in MIME format. --------------618A3E9CC74C1DE7FC603227 Content-Type: text/plain; charset=utf-8; format=flowed Content-Transfer-Encoding: 8bit I also tried with '-n' for slappasswd, in the test below, for '-T' and '-s' cases. It changed nothing. On 12/12/2019 14:59, Antoine Tran wrote: > On 12/12/2019 14:02, Howard Chu wrote: >> antoine.tran(a)thales-services.fr wrote: >>> Full_Name: Antoine TRAN >>> Version: openldap-servers-2.4.44-21.el7_6.x86_64 >>> OS: CentOS Linux release 7.7.1908 (Core) >>> URL:ftp://ftp.openldap.org/incoming/ >>> Submission from: (NULL) (213.190.88.94) >>> >>> >>> I use slappasswd to generate SSHA password. The issue is it behavior is >>> different whether I submit the password - in stdin or in command-line '-s' - and >>> from a secret file '-T'. Command: >>> slappasswd -h {SSHA} >>> => write 'd' twice as password >>> slappasswd -h {SSHA} -s d >>> >>> provides working SSHA. >>> >>> But: >>> echo d >/run/secrets/rootpw >>> slappasswd -h {SSHA} -T /run/secrets/rootpw >>> provides a valid SSHA, but that does not match the password. >>> >>> My multiple test are done by replacing rootpw in /etc/openldap/slapd.conf, >>> regenerating with: >>> systemctl stop slapd >>> sed -i -e "s,rootpw .*\$,rootpw ${ROOTPW_HASH},g" /etc/openldap/slapd.conf >>> slapcat -n 0 -f /etc/openldap/slapd.conf -F /etc/openldap/slapd.d >>> systemctl start slapd >>> ldapsearch -D "${ROOTDN}" -w "${ROOTPW}" >>> >>> The content of the secret file can be "d" or "d\n", it does not make a >>> difference. Also, if I change the schema from SSHA to just a fixed salt, the >>> '-T' seems to work as expected: >>> (a) slappasswd -c 123 >>> => write d twice >>> (b) slappasswd -c 123 -s 123 >>> (c) slappasswd -c 123 -T /run/secrets/rootpw >>> >>> (a), (b) and (c) gives the exact same hash. But I cannot put a fixed salt and >>> use SSHA, slappasswd prevents me from that, with an error schema already >>> provided. >> Unable to reproduce, SSHA works fine here. >> >> Obviously you can't use a fixed salt with SSHA, that's the point of its salt is to >> be random and different every time. > I wanted to override the salt as a test, to check if we have the same > output with a file and in command-line. But I found another way to test. >> When using a password in a file you must ensure the trailing '\n' is omitted. This >> is already documented in the manpage. > > I did read and checked this point. I have written that I did not have > a newline. But here is a simple and reproducible test, that took me > some long time. In a Linux machine with internet, just copy paste this: > > docker run --name slappasswd --rm -ti centos:7 bash > > yum install openldap-servers -y > > cat <<EOF >/makeSecret.py > import os > import sys > import hashlib > from base64 import urlsafe_b64encode as encode > from base64 import urlsafe_b64decode as decode > > def makeSecret(password): > salt = os.urandom(4) > h = hashlib.sha1(password) > h.update(salt) > return "{SSHA}" + encode(h.digest() + salt) > > if __name__ == '__main__': > print(makeSecret(sys.argv[1])) > EOF > > cat <<EOF >/checkPassword.py > import os > import sys > import hashlib > from base64 import urlsafe_b64encode as encode > from base64 import urlsafe_b64decode as decode > > def checkPassword(challenge_password, password): > challenge_bytes = decode(challenge_password[6:]) > digest = challenge_bytes[:20] > salt = challenge_bytes[20:] > hr = hashlib.sha1(password) > hr.update(salt) > return digest == hr.digest() > > if __name__ == '__main__': > print(checkPassword(sys.argv[1], sys.argv[2])) > EOF > > python /checkPassword.py $(python /makeSecret.py d) d > > python /checkPassword.py $(slappasswd -s d) d > > mkdir -p /run/secrets/ > echo d>/run/secrets/rootpw > python /checkPassword.py $(slappasswd -T /run/secrets/rootpw) d > echo Begin-$(cat /run/secrets/rootpw)-End > # => shows no newline: > #Begin-d-End > > It will show you that all hash works except the part with slappasswd > -T, and I checked the newline. > >>> I saw the same issue in another openldap mail: >>> https://www.openldap.org/lists/openldap-software/200805/msg00060.html but no >>> answer. >>> >>> --------------618A3E9CC74C1DE7FC603227 Content-Type: text/html; charset=utf-8 Content-Transfer-Encoding: 8bit <html> <head> <meta http-equiv="Content-Type" content="text/html; charset=UTF-8"> </head> <body text="#000000" bgcolor="#FFFFFF"> I also tried with '-n' for slappasswd, in the test below, for '-T' and '-s' cases. It changed nothing. On 12/12/2019 14:59, Antoine Tran wrote: <blockquote type="cite" cite="mid:948b761f-cb48-024a-dbb2-970493a9def2@thales-services.fr"> <meta http-equiv="Content-Type" content="text/html; charset=UTF-8"> On 12/12/2019 14:02, Howard Chu wrote: <blockquote type="cite" cite="mid:c5070626-b60e-28f5-38a3-7871c8a0cbec@symas.com"> <pre class="moz-quote-pre" wrap=""><a class="moz-txt-link-abbreviated" href="mailto:antoine.tran@thales-services.fr" moz-do-not-send="true">antoine.tran(a)thales-services.fr</a> wrote: </pre> <blockquote type="cite"> <pre class="moz-quote-pre" wrap="">Full_Name: Antoine TRAN Version: openldap-servers-2.4.44-21.el7_6.x86_64 OS: CentOS Linux release 7.7.1908 (Core) URL: <a class="moz-txt-link-freetext" href="ftp://ftp.openldap.org/incoming/" moz-do-not-send="true">ftp://ftp.openldap.org/incoming/</a> Submission from: (NULL) (213.190.88.94) I use slappasswd to generate SSHA password. The issue is it behavior is different whether I submit the password - in stdin or in command-line '-s' - and from a secret file '-T'. Command: slappasswd -h {SSHA} => write 'd' twice as password slappasswd -h {SSHA} -s d provides working SSHA. But: echo d >/run/secrets/rootpw slappasswd -h {SSHA} -T /run/secrets/rootpw provides a valid SSHA, but that does not match the password. My multiple test are done by replacing rootpw in /etc/openldap/slapd.conf, regenerating with: systemctl stop slapd sed -i -e "s,rootpw .*\$,rootpw ${ROOTPW_HASH},g" /etc/openldap/slapd.conf slapcat -n 0 -f /etc/openldap/slapd.conf -F /etc/openldap/slapd.d systemctl start slapd ldapsearch -D "${ROOTDN}" -w "${ROOTPW}" The content of the secret file can be "d" or "d\n", it does not make a difference. Also, if I change the schema from SSHA to just a fixed salt, the '-T' seems to work as expected: (a) slappasswd -c 123 => write d twice (b) slappasswd -c 123 -s 123 (c) slappasswd -c 123 -T /run/secrets/rootpw (a), (b) and (c) gives the exact same hash. But I cannot put a fixed salt and use SSHA, slappasswd prevents me from that, with an error schema already provided. </pre> </blockquote> <pre class="moz-quote-pre" wrap="">Unable to reproduce, SSHA works fine here. Obviously you can't use a fixed salt with SSHA, that's the point of its salt is to be random and different every time.</pre> </blockquote> I wanted to override the salt as a test, to check if we have the same output with a file and in command-line. But I found another way to test. <blockquote type="cite" cite="mid:c5070626-b60e-28f5-38a3-7871c8a0cbec@symas.com"> <pre class="moz-quote-pre" wrap="">When using a password in a file you must ensure the trailing '\n' is omitted. This is already documented in the manpage.</pre> </blockquote> I did read and checked this point. I have written that I did not have a newline. But here is a simple and reproducible test, that took me some long time. In a Linux machine with internet, just copy paste this: <blockquote> docker run --name slappasswd --rm -ti centos:7 bash yum install openldap-servers -y cat <<EOF >/makeSecret.py import os import sys import hashlib from base64 import urlsafe_b64encode as encode from base64 import urlsafe_b64decode as decode def makeSecret(password): salt = os.urandom(4) h = hashlib.sha1(password) h.update(salt) return "{SSHA}" + encode(h.digest() + salt) if __name__ == '__main__': print(makeSecret(sys.argv[1])) EOF cat <<EOF >/checkPassword.py import os import sys import hashlib from base64 import urlsafe_b64encode as encode from base64 import urlsafe_b64decode as decode def checkPassword(challenge_password, password): challenge_bytes = decode(challenge_password[6:]) digest = challenge_bytes[:20] salt = challenge_bytes[20:] hr = hashlib.sha1(password) hr.update(salt) return digest == hr.digest() if __name__ == '__main__': print(checkPassword(sys.argv[1], sys.argv[2])) EOF python /checkPassword.py $(python /makeSecret.py d) d python /checkPassword.py $(slappasswd -s d) d mkdir -p /run/secrets/ echo d>/run/secrets/rootpw python /checkPassword.py $(slappasswd -T /run/secrets/rootpw) d echo Begin-$(cat /run/secrets/rootpw)-End # => shows no newline: #Begin-d-End </blockquote> It will show you that all hash works except the part with slappasswd -T, and I checked the newline. <blockquote type="cite" cite="mid:c5070626-b60e-28f5-38a3-7871c8a0cbec@symas.com"> <blockquote type="cite"> <pre class="moz-quote-pre" wrap="">I saw the same issue in another openldap mail: <a class="moz-txt-link-freetext" href="https://www.openldap.org/lists/openldap-software/200805/msg00060.html" moz-do-not-send="true">https://www.openldap.org/lists/openldap-software/200805/msg00060.html</a> but no answer. </pre> </blockquote> </blockquote> </blockquote> </body> </html> --------------618A3E9CC74C1DE7FC603227--

1 0

Re: (ITS#9137) slappasswd generate wrong SSHA from file
by antoine.tran＠thales-services.fr 12 Dec '19

12 Dec '19

This is a multi-part message in MIME format. --------------0657C2ED691C0A313ADDDE9F Content-Type: text/plain; charset=utf-8; format=flowed Content-Transfer-Encoding: 8bit On 12/12/2019 14:02, Howard Chu wrote: > antoine.tran(a)thales-services.fr wrote: >> Full_Name: Antoine TRAN >> Version: openldap-servers-2.4.44-21.el7_6.x86_64 >> OS: CentOS Linux release 7.7.1908 (Core) >> URL: ftp://ftp.openldap.org/incoming/ >> Submission from: (NULL) (213.190.88.94) >> >> >> I use slappasswd to generate SSHA password. The issue is it behavior is >> different whether I submit the password - in stdin or in command-line '-s' - and >> from a secret file '-T'. Command: >> slappasswd -h {SSHA} >> => write 'd' twice as password >> slappasswd -h {SSHA} -s d >> >> provides working SSHA. >> >> But: >> echo d >/run/secrets/rootpw >> slappasswd -h {SSHA} -T /run/secrets/rootpw >> provides a valid SSHA, but that does not match the password. >> >> My multiple test are done by replacing rootpw in /etc/openldap/slapd.conf, >> regenerating with: >> systemctl stop slapd >> sed -i -e "s,rootpw .*\$,rootpw ${ROOTPW_HASH},g" /etc/openldap/slapd.conf >> slapcat -n 0 -f /etc/openldap/slapd.conf -F /etc/openldap/slapd.d >> systemctl start slapd >> ldapsearch -D "${ROOTDN}" -w "${ROOTPW}" >> >> The content of the secret file can be "d" or "d\n", it does not make a >> difference. Also, if I change the schema from SSHA to just a fixed salt, the >> '-T' seems to work as expected: >> (a) slappasswd -c 123 >> => write d twice >> (b) slappasswd -c 123 -s 123 >> (c) slappasswd -c 123 -T /run/secrets/rootpw >> >> (a), (b) and (c) gives the exact same hash. But I cannot put a fixed salt and >> use SSHA, slappasswd prevents me from that, with an error schema already >> provided. > Unable to reproduce, SSHA works fine here. > > Obviously you can't use a fixed salt with SSHA, that's the point of its salt is to > be random and different every time. I wanted to override the salt as a test, to check if we have the same output with a file and in command-line. But I found another way to test. > > When using a password in a file you must ensure the trailing '\n' is omitted. This > is already documented in the manpage. I did read and checked this point. I have written that I did not have a newline. But here is a simple and reproducible test, that took me some long time. In a Linux machine with internet, just copy paste this: docker run --name slappasswd --rm -ti centos:7 bash yum install openldap-servers -y cat <<EOF >/makeSecret.py import os import sys import hashlib from base64 import urlsafe_b64encode as encode from base64 import urlsafe_b64decode as decode def makeSecret(password): salt = os.urandom(4) h = hashlib.sha1(password) h.update(salt) return "{SSHA}" + encode(h.digest() + salt) if __name__ == '__main__': print(makeSecret(sys.argv[1])) EOF cat <<EOF >/checkPassword.py import os import sys import hashlib from base64 import urlsafe_b64encode as encode from base64 import urlsafe_b64decode as decode def checkPassword(challenge_password, password): challenge_bytes = decode(challenge_password[6:]) digest = challenge_bytes[:20] salt = challenge_bytes[20:] hr = hashlib.sha1(password) hr.update(salt) return digest == hr.digest() if __name__ == '__main__': print(checkPassword(sys.argv[1], sys.argv[2])) EOF python /checkPassword.py $(python /makeSecret.py d) d python /checkPassword.py $(slappasswd -s d) d mkdir -p /run/secrets/ echo d>/run/secrets/rootpw python /checkPassword.py $(slappasswd -T /run/secrets/rootpw) d echo Begin-$(cat /run/secrets/rootpw)-End # => shows no newline: #Begin-d-End It will show you that all hash works except the part with slappasswd -T, and I checked the newline. > >> I saw the same issue in another openldap mail: >> https://www.openldap.org/lists/openldap-software/200805/msg00060.html but no >> answer. >> >> > --------------0657C2ED691C0A313ADDDE9F Content-Type: text/html; charset=utf-8 Content-Transfer-Encoding: 8bit <html> <head> <meta http-equiv="Content-Type" content="text/html; charset=UTF-8"> </head> <body text="#000000" bgcolor="#FFFFFF"> On 12/12/2019 14:02, Howard Chu wrote: <blockquote type="cite" cite="mid:c5070626-b60e-28f5-38a3-7871c8a0cbec@symas.com"> <pre class="moz-quote-pre" wrap=""><a class="moz-txt-link-abbreviated" href="mailto:antoine.tran@thales-services.fr">antoine.tran(a)thales-services.fr</a> wrote: </pre> <blockquote type="cite"> <pre class="moz-quote-pre" wrap="">Full_Name: Antoine TRAN Version: openldap-servers-2.4.44-21.el7_6.x86_64 OS: CentOS Linux release 7.7.1908 (Core) URL: <a class="moz-txt-link-freetext" href="ftp://ftp.openldap.org/incoming/">ftp://ftp.openldap.org/incoming/</a> Submission from: (NULL) (213.190.88.94) I use slappasswd to generate SSHA password. The issue is it behavior is different whether I submit the password - in stdin or in command-line '-s' - and from a secret file '-T'. Command: slappasswd -h {SSHA} => write 'd' twice as password slappasswd -h {SSHA} -s d provides working SSHA. But: echo d >/run/secrets/rootpw slappasswd -h {SSHA} -T /run/secrets/rootpw provides a valid SSHA, but that does not match the password. My multiple test are done by replacing rootpw in /etc/openldap/slapd.conf, regenerating with: systemctl stop slapd sed -i -e "s,rootpw .*\$,rootpw ${ROOTPW_HASH},g" /etc/openldap/slapd.conf slapcat -n 0 -f /etc/openldap/slapd.conf -F /etc/openldap/slapd.d systemctl start slapd ldapsearch -D "${ROOTDN}" -w "${ROOTPW}" The content of the secret file can be "d" or "d\n", it does not make a difference. Also, if I change the schema from SSHA to just a fixed salt, the '-T' seems to work as expected: (a) slappasswd -c 123 => write d twice (b) slappasswd -c 123 -s 123 (c) slappasswd -c 123 -T /run/secrets/rootpw (a), (b) and (c) gives the exact same hash. But I cannot put a fixed salt and use SSHA, slappasswd prevents me from that, with an error schema already provided. </pre> </blockquote> <pre class="moz-quote-pre" wrap=""> Unable to reproduce, SSHA works fine here. Obviously you can't use a fixed salt with SSHA, that's the point of its salt is to be random and different every time.</pre> </blockquote> I wanted to override the salt as a test, to check if we have the same output with a file and in command-line. But I found another way to test. <blockquote type="cite" cite="mid:c5070626-b60e-28f5-38a3-7871c8a0cbec@symas.com"> <pre class="moz-quote-pre" wrap=""> When using a password in a file you must ensure the trailing '\n' is omitted. This is already documented in the manpage.</pre> </blockquote> I did read and checked this point. I have written that I did not have a newline. But here is a simple and reproducible test, that took me some long time. In a Linux machine with internet, just copy paste this: <blockquote> docker run --name slappasswd --rm -ti centos:7 bash yum install openldap-servers -y cat <<EOF >/makeSecret.py import os import sys import hashlib from base64 import urlsafe_b64encode as encode from base64 import urlsafe_b64decode as decode def makeSecret(password): salt = os.urandom(4) h = hashlib.sha1(password) h.update(salt) return "{SSHA}" + encode(h.digest() + salt) if __name__ == '__main__': print(makeSecret(sys.argv[1])) EOF cat <<EOF >/checkPassword.py import os import sys import hashlib from base64 import urlsafe_b64encode as encode from base64 import urlsafe_b64decode as decode def checkPassword(challenge_password, password): challenge_bytes = decode(challenge_password[6:]) digest = challenge_bytes[:20] salt = challenge_bytes[20:] hr = hashlib.sha1(password) hr.update(salt) return digest == hr.digest() if __name__ == '__main__': print(checkPassword(sys.argv[1], sys.argv[2])) EOF python /checkPassword.py $(python /makeSecret.py d) d python /checkPassword.py $(slappasswd -s d) d mkdir -p /run/secrets/ echo d>/run/secrets/rootpw python /checkPassword.py $(slappasswd -T /run/secrets/rootpw) d echo Begin-$(cat /run/secrets/rootpw)-End # => shows no newline: #Begin-d-End </blockquote> It will show you that all hash works except the part with slappasswd -T, and I checked the newline. <blockquote type="cite" cite="mid:c5070626-b60e-28f5-38a3-7871c8a0cbec@symas.com"> <pre class="moz-quote-pre" wrap=""> </pre> <blockquote type="cite"> <pre class="moz-quote-pre" wrap=""> I saw the same issue in another openldap mail: <a class="moz-txt-link-freetext" href="https://www.openldap.org/lists/openldap-software/200805/msg00060.html">https://www.openldap.org/lists/openldap-software/200805/msg00060.html</a> but no answer. </pre> </blockquote> <pre class="moz-quote-pre" wrap=""> </pre> </blockquote> </body> </html> --------------0657C2ED691C0A313ADDDE9F--

1 0

(ITS#9138)
by scf＠ieee.org 12 Dec '19

12 Dec '19

Howards mentioned in another wrongly submitted issue (#9139) that "memcmp.c isn't even referenced in the Makefile, so none of this code is used." Here is the clarification, even if memcmp.c is not used, gcc or other compilers' implementations of memcmp is still unsafe (https://github.com/gcc-mirror/gcc/blob/master/libiberty/memcmp.c). -- Best regards, Shou C

1 0

Re: (ITS#9139) Side
by hyc＠symas.com 12 Dec '19

12 Dec '19

scf(a)ieee.org wrote: > Full_Name: Shou Chaofan > Version: > OS: > URL: ftp://ftp.openldap.org/incoming/ > Submission from: (NULL) (98.185.228.137) > > > Here is the implementation of lutil_memcmp at /libraries/liblutil/memcmp.c memcmp.c isn't even referenced in the Makefile, so none of this code is used. Closing this ITS. -- -- Howard Chu CTO, Symas Corp. http://www.symas.com Director, Highland Sun http://highlandsun.com/hyc/ Chief Architect, OpenLDAP http://www.openldap.org/project/

1 0

ITS#1941
by scf＠ieee.org 12 Dec '19

12 Dec '19

--000000000000a68521059981b791 Content-Type: text/plain; charset="UTF-8" Please close this issue. It is wrongly sent by browser. --000000000000a68521059981b791 Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable <div dir=3D"ltr"><div class=3D"gmail-gs" style=3D"margin:0px;padding:0px 0p= x 20px;width:760px;font-family:Roboto,RobotoDraft,Helvetica,Arial,sans-seri= f;font-size:medium"><div class=3D"gmail-"><div id=3D"gmail-:1i9" class=3D"g= mail-ii gmail-gt" style=3D"font-size:0.875rem;direction:ltr;margin:8px 0px = 0px;padding:0px"><div id=3D"gmail-:1gp" class=3D"gmail-a3s gmail-aXjCH" sty= le=3D"overflow:hidden;font-variant-numeric:normal;font-variant-east-asian:n= ormal;font-stretch:normal;font-size:small;line-height:1.5;font-family:Arial= ,Helvetica,sans-serif"><div dir=3D"ltr">Please close this issue. It is wron= gly sent by browser.</div><div class=3D"gmail-yj6qo"></div><div class=3D"gm= ail-adL"></div></div></div><div class=3D"gmail-hi" style=3D"border-bottom-l= eft-radius:1px;border-bottom-right-radius:1px;padding:0px;width:auto;backgr= ound:rgb(242,242,242);margin:0px"></div></div></div> </div> --000000000000a68521059981b791--

1 0

Jump to page:

2025

2024

2023

2022

2021

2020

2019

2018

2017

2016

2015

2014

2013

2012

2011

2010

2009

2008

2007

2006

openldap-bugs