openldap-bugs December 2019

openldap-bugs@openldap.org

15 participants
41 discussions

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"> <p>I also tried with '-n' for slappasswd, in the test below, for '-T' and '-s' cases. It changed nothing.<br> </p> <p>On 12/12/2019 14:59, Antoine Tran wrote:</p> <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:<br> <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.<br> <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> <p>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:</p> <blockquote> <p>docker run --name slappasswd --rm -ti centos:7 bash<br> <br> yum install openldap-servers -y<br> <br> cat <<EOF >/makeSecret.py<br> import os<br> import sys<br> import hashlib<br> from base64 import urlsafe_b64encode as encode<br> from base64 import urlsafe_b64decode as decode<br> <br> def makeSecret(password):<br> salt = os.urandom(4)<br> h = hashlib.sha1(password)<br> h.update(salt)<br> return "{SSHA}" + encode(h.digest() + salt)<br> <br> if __name__ == '__main__':<br> print(makeSecret(sys.argv[1]))<br> EOF<br> <br> cat <<EOF >/checkPassword.py<br> import os<br> import sys<br> import hashlib<br> from base64 import urlsafe_b64encode as encode<br> from base64 import urlsafe_b64decode as decode<br> <br> def checkPassword(challenge_password, password):<br> challenge_bytes = decode(challenge_password[6:])<br> digest = challenge_bytes[:20]<br> salt = challenge_bytes[20:]<br> hr = hashlib.sha1(password)<br> hr.update(salt)<br> return digest == hr.digest()<br> <br> if __name__ == '__main__':<br> print(checkPassword(sys.argv[1], sys.argv[2]))<br> EOF<br> <br> python /checkPassword.py $(python /makeSecret.py d) d<br> <br> python /checkPassword.py $(slappasswd -s d) d<br> <br> mkdir -p /run/secrets/<br> echo d>/run/secrets/rootpw<br> python /checkPassword.py $(slappasswd -T /run/secrets/rootpw) d<br> echo Begin-$(cat /run/secrets/rootpw)-End<br> # => shows no newline:<br> #Begin-d-End<br> </p> </blockquote> <p>It will show you that all hash works except the part with slappasswd -T, and I checked the newline.<br> <br> </p> <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:<br> <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.<br> <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> <p>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:</p> <blockquote> <p>docker run --name slappasswd --rm -ti centos:7 bash<br> <br> yum install openldap-servers -y<br> <br> cat <<EOF >/makeSecret.py<br> import os<br> import sys<br> import hashlib<br> from base64 import urlsafe_b64encode as encode<br> from base64 import urlsafe_b64decode as decode<br> <br> def makeSecret(password):<br> salt = os.urandom(4)<br> h = hashlib.sha1(password)<br> h.update(salt)<br> return "{SSHA}" + encode(h.digest() + salt)<br> <br> if __name__ == '__main__':<br> print(makeSecret(sys.argv[1]))<br> EOF<br> <br> cat <<EOF >/checkPassword.py<br> import os<br> import sys<br> import hashlib<br> from base64 import urlsafe_b64encode as encode<br> from base64 import urlsafe_b64decode as decode<br> <br> def checkPassword(challenge_password, password):<br> challenge_bytes = decode(challenge_password[6:])<br> digest = challenge_bytes[:20]<br> salt = challenge_bytes[20:]<br> hr = hashlib.sha1(password)<br> hr.update(salt)<br> return digest == hr.digest()<br> <br> if __name__ == '__main__':<br> print(checkPassword(sys.argv[1], sys.argv[2]))<br> EOF<br> <br> python /checkPassword.py $(python /makeSecret.py d) d<br> <br> python /checkPassword.py $(slappasswd -s d) d<br> <br> mkdir -p /run/secrets/<br> echo d>/run/secrets/rootpw<br> python /checkPassword.py $(slappasswd -T /run/secrets/rootpw) d<br> echo Begin-$(cat /run/secrets/rootpw)-End<br> # => shows no newline:<br> #Begin-d-End<br> </p> </blockquote> <p>It will show you that all hash works except the part with slappasswd -T, and I checked the newline.<br> <br> </p> <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><br class=3D"gmail-Appl= e-interchange-newline"></div> --000000000000a68521059981b791--

1 0

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

12 Dec '19

--000000000000c18e69059981b6c8 Content-Type: text/plain; charset="UTF-8" Please close this issue. It is wrongly sent by browser. --000000000000c18e69059981b6c8 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></div></div></div></div> --000000000000c18e69059981b6c8--

1 0

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

12 Dec '19

--000000000000affb38059981b483 Content-Type: text/plain; charset="UTF-8" Please close this issue. It is wrongly sent by browser. --000000000000affb38059981b483 Content-Type: text/html; charset="UTF-8" <div dir="ltr">Please close this issue. It is wrongly sent by browser.</div> --000000000000affb38059981b483--

1 0

(ITS#9141) Side channel vulnerability at password check
by scf＠ieee.org 12 Dec '19

12 Dec '19

Full_Name: Shou C Version: 2.4.48 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 int (lutil_memcmp)(const void *v1, const void *v2, size_t n) { if (n != 0) { const unsigned char *s1=v1, *s2=v2; do { if (*s1++ != *s2++) return *--s1 - *--s2; // immediate return after difference } while (--n != 0); } return 0; } Later, it is redefined as memcpy. Then this function is used in the password checking function to compare user password and inputed password. This would lead to a timing attack / side channel attack. Here are all usages related to comparison of plaintext password /libraries/liblutil/passwd.c: 341 if( is_allowed_scheme("{CLEARTEXT}", schemes ) ) { return ( passwd->bv_len == cred->bv_len ) ? memcmp( passwd->bv_val, cred->bv_val, passwd->bv_len ) : 1; } Here are all usages related to comparison of hashed password (although this is less exploitable, by bruteforcing based on hash value, with enough time, attacker could still recover the password): /contrib/slapd-modules/passwd/sha2/slapd-sha2.c:262 rc = memcmp((char *)orig_pass, (char *)SHAdigest, sizeof(SHAdigest)); /contrib/slapd-modules/passwd/sha2/slapd-sha2.c:303 rc = memcmp((char *)orig_pass, (char *)SHAdigest, sizeof(SHAdigest)); /contrib/slapd-modules/passwd/sha2/slapd-sha2.c:350 rc = memcmp((char *)orig_pass, (char *)SHAdigest, sizeof(SHAdigest)); /contrib/slapd-modules/passwd/sha2/slapd-sha2.c:391 rc = memcmp((char *)orig_pass, (char *)SHAdigest, sizeof(SHAdigest)); /contrib/slapd-modules/passwd/sha2/slapd-sha2.c:438 rc = memcmp((char *)orig_pass, (char *)SHAdigest, sizeof(SHAdigest)); /contrib/slapd-modules/passwd/sha2/slapd-sha2.c:479 rc = memcmp((char *)orig_pass, (char *)SHAdigest, sizeof(SHAdigest)); /libraries/liblutil/passwd.c: 526 rc = memcmp((char *)orig_pass, (char *)SHA1digest, sizeof(SHA1digest)); /libraries/liblutil/passwd.c: 567 rc = memcmp((char *)orig_pass, (char *)SHA1digest, sizeof(SHA1digest)); /libraries/liblutil/passwd.c: 613 rc = memcmp((char *)orig_pass, (char *)MD5digest, sizeof(MD5digest)); /libraries/liblutil/passwd.c: 654 rc = memcmp((char *)orig_pass, (char *)MD5digest, sizeof(MD5digest)); /libraries/liblutil/passwd.c: 894 return memcmp( PasswordHash, storedPasswordHash, 32) ? LUTIL_PASSWD_ERR : LUTIL_PASSWD_OK; etc.. A safer implementation is: int (lutil_safe_memcmp)(const void *v1, const void *v2, size_t n) { int c=0; if (n != 0) { const unsigned char *s1=v1, *s2=v2; do { if (*s1++ != *s2++ && c == 0) c += *--s1 - *--s2; } while (--n != 0); } return c; }

1 0

(ITS#9140) Side channel vulnerability at password check
by scf＠ieee.org 12 Dec '19

12 Dec '19

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 int (lutil_memcmp)(const void *v1, const void *v2, size_t n) { if (n != 0) { const unsigned char *s1=v1, *s2=v2; do { if (*s1++ != *s2++) return *--s1 - *--s2; // immediate return after difference } while (--n != 0); } return 0; } Later, it is redefined as memcpy. Then this function is used in the password checking function to compare user password and inputed password. This would lead to a timing attack / side channel attack. Here are all usages related to comparison of plaintext password /libraries/liblutil/passwd.c: 341 if( is_allowed_scheme("{CLEARTEXT}", schemes ) ) { return ( passwd->bv_len == cred->bv_len ) ? memcmp( passwd->bv_val, cred->bv_val, passwd->bv_len ) : 1; } Here are all usages related to comparison of hashed password (although this is less exploitable, by bruteforcing based on hash value, with enough time, attacker could still recover the password): /contrib/slapd-modules/passwd/sha2/slapd-sha2.c:262 rc = memcmp((char *)orig_pass, (char *)SHAdigest, sizeof(SHAdigest)); /contrib/slapd-modules/passwd/sha2/slapd-sha2.c:303 rc = memcmp((char *)orig_pass, (char *)SHAdigest, sizeof(SHAdigest)); /contrib/slapd-modules/passwd/sha2/slapd-sha2.c:350 rc = memcmp((char *)orig_pass, (char *)SHAdigest, sizeof(SHAdigest)); /contrib/slapd-modules/passwd/sha2/slapd-sha2.c:391 rc = memcmp((char *)orig_pass, (char *)SHAdigest, sizeof(SHAdigest)); /contrib/slapd-modules/passwd/sha2/slapd-sha2.c:438 rc = memcmp((char *)orig_pass, (char *)SHAdigest, sizeof(SHAdigest)); /contrib/slapd-modules/passwd/sha2/slapd-sha2.c:479 rc = memcmp((char *)orig_pass, (char *)SHAdigest, sizeof(SHAdigest)); /libraries/liblutil/passwd.c: 526 rc = memcmp((char *)orig_pass, (char *)SHA1digest, sizeof(SHA1digest)); /libraries/liblutil/passwd.c: 567 rc = memcmp((char *)orig_pass, (char *)SHA1digest, sizeof(SHA1digest)); /libraries/liblutil/passwd.c: 613 rc = memcmp((char *)orig_pass, (char *)MD5digest, sizeof(MD5digest)); /libraries/liblutil/passwd.c: 654 rc = memcmp((char *)orig_pass, (char *)MD5digest, sizeof(MD5digest)); /libraries/liblutil/passwd.c: 894 return memcmp( PasswordHash, storedPasswordHash, 32) ? LUTIL_PASSWD_ERR : LUTIL_PASSWD_OK; etc.. A safer implementation is: int (lutil_safe_memcmp)(const void *v1, const void *v2, size_t n) { int c=0; if (n != 0) { const unsigned char *s1=v1, *s2=v2; do { if (*s1++ != *s2++ && c == 0) c += *--s1 - *--s2; } while (--n != 0); } return c; }

1 0

2024

2023

2022

2021

2020

2019

2018

2017

2016

2015

2014

2013

2012

2011

2010

2009

2008

2007

2006

openldap-bugs December 2019