openldap-bugs December 2019

openldap-bugs@openldap.org

15 participants
41 discussions

Start a nNew thread

Re: (ITS#9144) Remove ICU detection
by ryan＠nardis.ca 19 Dec '19

19 Dec '19

Patch available: https://github.com/openldap/openldap/compare/master...rtandy:its9144.patch

1 0

Re: (ITS#9143) Segfault in libcrypto.so.1.1
by quanah＠symas.com 19 Dec '19

19 Dec '19

--On Thursday, December 19, 2019 9:46 PM +0000 quanah(a)symas.com wrote: > > > --On Saturday, December 14, 2019 10:54 PM +0000 s.peillon(a)caenlamer.fr > wrote: > >> Can you tell me what to modify to correct this error? > > Hello, > > Libcrypto is not provided by the OpenLDAP project. I would also note > that Debian & Ubuntu use GnuTLS by default rather than OpenSSL. I would > advise contacting the Debian/Ubuntu project and their GnuTLS package > maintainers specifically. If you are building your own OpenLDAP linked to your own OpenSSL build, you'll need to dig deeper into the issues, as you're a bit outside of what Debian/Ubuntu do with OpenLDAP. I would note that at least for Ubuntu 18, there is already a backport provided of the 2.4.48 release that does not appear to exhibit the issues you describe. 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#9143) Segfault in libcrypto.so.1.1
by quanah＠symas.com 19 Dec '19

19 Dec '19

--On Saturday, December 14, 2019 10:54 PM +0000 s.peillon(a)caenlamer.fr wrote: > Can you tell me what to modify to correct this error? Hello, Libcrypto is not provided by the OpenLDAP project. I would also note that Debian & Ubuntu use GnuTLS by default rather than OpenSSL. I would advise contacting the Debian/Ubuntu project and their GnuTLS package maintainers specifically. 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#9144) Remove ICU detection
by quanah＠symas.com 19 Dec '19

19 Dec '19

--On Thursday, December 19, 2019 9:36 PM +0000 quanah(a)openldap.org wrote: > 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. See also commits a956f7592 and 1cf5838e0 I found this to be a problem when slapd is compiled on a system where the ICU libs are present and then the build is later deployed on a system where it doesn't exist, causing slapd to fail. --Quanah -- Quanah Gibson-Mount Product Architect Symas Corporation Packaged, certified, and supported LDAP solutions powered by OpenLDAP: <http://www.symas.com>

1 0

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

15 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 12 Dec '19

12 Dec '19

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

1 0

2025

2024

2023

2022

2021

2020

2019

2018

2017

2016

2015

2014

2013

2012

2011

2010

2009

2008

2007

2006

openldap-bugs December 2019