- openldap-bugs - openldap.org

(ITS#9151) slapd-sock - stumped
by matthew＠schlutech.com 11 Jan '20

11 Jan '20

Full_Name: W. Matthew Schlueter Version: 2.4.45+dfsg-1ubuntu1.4 OS: Ubuntu 18.04.3 LTS URL: ftp://ftp.openldap.org/incoming/ Submission from: (NULL) (172.101.204.19) Always results in socket connect failed. Using the examples from the source tree: modulepath /usr/lib/ldap moduleload back_sock.so include /etc/ldap/schema/core.schema database sock socketpath /tmp/example.sock suffix "dc=test,dc=com" Starting slapd: slapd -4 -f /etc/ldap/slapd.conf -u root -g root -d1 Using the perl script example from the source tree plus tried endless debugging with my own code. File permissions all look correct. Scoured for answers. Stumped. Always: socket connect(/root/example.sock) failed

1 0

Re: (ITS#9150) olcDbNoSync: FALSE has the same effect as olcDbNoSync: TRUE
by hyc＠symas.com 11 Jan '20

11 Jan '20

maxime.besson(a)worteks.com wrote: > Full_Name: Maxime Besson > Version: 2.4.48 > OS: Debian Buster / CentOS7 > URL: ftp://ftp.openldap.org/incoming/ > Submission from: (NULL) (2a01:cb00:802:8400:2cbe:3c60:fca6:e50b) > > > While migrating configuration from slapd.conf to cn=config, I noticed something > pretty strange related to the dbnosync option Thanks for the report, fixed now in git master. > > The result of converting the following config: > > include ./core.schema > pidfile ./slapd.1.pid > argsfile ./slapd.1.args > > > database mdb > suffix "dc=example,dc=com" > rootdn "cn=Manager,dc=example,dc=com" > rootpw secret > directory db.1.a > index objectClass eq > index cn,sn,uid pres,eq,sub > index entryUUID,entryCSN eq > > > Is (only interested in MDB config): > # AUTO-GENERATED FILE - DO NOT EDIT!! Use ldapmodify. > # CRC32 3df9c3d6 > dn: olcDatabase={1}mdb > objectClass: olcDatabaseConfig > objectClass: olcMdbConfig > olcDatabase: {1}mdb > olcSuffix: dc=example,dc=com > olcAddContentAcl: FALSE > olcLastMod: TRUE > olcMaxDerefDepth: 15 > olcReadOnly: FALSE > olcRootDN: cn=Manager,dc=example,dc=com > olcRootPW:: c2VjcmV0 > olcSyncUseSubentry: FALSE > olcMonitoring: TRUE > olcDbDirectory: db.1.a > olcDbNoSync: FALSE > olcDbIndex: objectClass eq > olcDbIndex: entryUUID eq > olcDbIndex: entryCSN eq > olcDbIndex: cn pres,eq,sub > olcDbIndex: uid pres,eq,sub > olcDbIndex: sn pres,eq,sub > olcDbMaxReaders: 0 > olcDbMaxSize: 10485760 > olcDbMode: 0600 > olcDbSearchStack: 16 > olcDbMaxEntrySize: 0 > olcDbRtxnSize: 10000 > > > As you can see, olcDbNoSync has the value FALSE, because there was no "dbnosync" > option in slapd.conf, however, performance testing shows a dramatic increase in > write speed after slapd.d migration. Which seems odd to me. It seems like the > MDB database was not syncing to disk anymore despite olcDbNoSync being FALSE > > Removing olcDbNoSync: FALSE from cn=config did restore previous performance and > syncing behavior > > Looking at servers/slapd/back-mdb/config.c:723 I found this: > > case MDB_DBNOSYNC: > if ( c->value_int ) > mdb->mi_dbenv_flags |= MDB_NOSYNC; > else > mdb->mi_dbenv_flags ^= MDB_NOSYNC; > > > The else case seems wrong, I replaced it with > > case MDB_DBNOSYNC: > if ( c->value_int ) > mdb->mi_dbenv_flags |= MDB_NOSYNC; > else > mdb->mi_dbenv_flags &= ~MDB_NOSYNC; > > And it solves the issue on my system. > > Reproduced on master, and 2.4.48, on Debian > > -- -- 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#9147) syncrepl connexion leak when provider uses an expired certificate
by hyc＠symas.com 11 Jan '20

11 Jan '20

maxime.besson(a)worteks.com wrote: > Full_Name: Maxime Besson > Version: 2.4.48 > OS: Debian Buster / CentOS7 > URL: https://cloud.worteks.com/index.php/s/9CE6ALLaAfrxZW4/download > Submission from: (NULL) (92.184.104.113) Thanks for the report and testcase, fixed now in git master. > > > I have two OpenLDAP (2.4.48, Ubuntu) servers running with syncrepl in > mirrormode. > > One of my server's X509 certificates has recently expired, and I noticed that > while it was expired, the other node's connection count kept climbing until it > a "Max open files" condition. It seems that when a Syncrepl consumer encounters > a certificate error, the outgoing LDAP connection to the provider is never > closed. > > Attached to this bug you will find a test case to reproduce this behavior > > # runs a provider with a bogus certificate > # and a consumer with retry=3+ > sh test.sh > ... > TLS certificate verification: Error, self signed certificate > TLS trace: SSL3 alert write:fatal:unknown CA > TLS trace: SSL_connect:error in error > TLS: can't connect: error:1416F086:SSL > routines:tls_process_server_certificate:certificate verify failed (self signed > certificate). > 5e160966 slap_client_connect: URI=ldaps://127.0.1.1:6636/ > DN="cn=manager,dc=example,dc=com" ldap_sasl_bind_s failed (-1) > 5e160966 do_syncrepl: rid=001 rc -1 retrying > ... > and so on, every 3 seconds > > While the consumer retries, running lsof on its PID will reveal the connection > leak: > > 42u TCP localhost:45964->localhost.lan:6636 (CLOSE_WAIT) > 43u TCP localhost:45966->localhost.lan:6636 (CLOSE_WAIT) > 44u TCP localhost:45968->localhost.lan:6636 (CLOSE_WAIT) > 45u TCP localhost:45970->localhost.lan:6636 (CLOSE_WAIT) > 46u TCP localhost:45972->localhost.lan:6636 (CLOSE_WAIT) > 47u TCP localhost:45974->localhost.lan:6636 (CLOSE_WAIT) > 48u TCP localhost:45976->localhost.lan:6636 (CLOSE_WAIT) > 49u TCP localhost:45978->localhost.lan:6636 (CLOSE_WAIT) > 50u TCP localhost:45980->localhost.lan:6636 (CLOSE_WAIT) > 51u TCP localhost:45982->localhost.lan:6636 (CLOSE_WAIT) > 52u TCP localhost:45984->localhost.lan:6636 (CLOSE_WAIT) > 53u TCP localhost:45986->localhost.lan:6636 (CLOSE_WAIT) > 54u TCP localhost:45988->localhost.lan:6636 (CLOSE_WAIT) > 55u TCP localhost:45990->localhost.lan:6636 (CLOSE_WAIT) > 56u TCP localhost:45992->localhost.lan:6636 (CLOSE_WAIT) > 57u TCP localhost:45994->localhost.lan:6636 (CLOSE_WAIT) > 58u TCP localhost:45996->localhost.lan:6636 (CLOSE_WAIT) > 59u TCP localhost:45998->localhost.lan:6636 (CLOSE_WAIT) > 60u TCP localhost:46000->localhost.lan:6636 (CLOSE_WAIT) > 61u TCP localhost:46002->localhost.lan:6636 (CLOSE_WAIT) > 62u TCP localhost:46004->localhost.lan:6636 (CLOSE_WAIT) > 63u TCP localhost:46006->localhost.lan:6636 (CLOSE_WAIT) > 64u TCP localhost:46008->localhost.lan:6636 (CLOSE_WAIT) > > > Modifying the provider URL in slapd.2.conf with a wrong port causes the > syncrepl > consumer to fail and retry just as much, but without connection piling up in > CLOSE_WAIT state. > > This is not a very critical issue because it only affects servers who are in > already degraded condition (broken replication, invalid certificate on the > provider) but I thought it still was worth reporting. > > I was able to reproduce this issue on the git master branch, on released 2.4.48, > on Centos7 and on Debian Buster. > OpenSSL version on the debian system: 1.1.1d-0+deb10u2 > > -- -- 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) CVE-ID?
by michael＠stroeder.com 10 Jan '20

10 Jan '20

On 1/10/20 2:28 PM, Stephan Zeisberg wrote: > So far I have not requested a CVE-Id for the issue. That's what Howard > wrote in this regard: > >> 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.> > I am not aware of a release including the bugfix for the issue. If the > release already exists I am happy to request a CVE-Id for it First of all, many thanks for finding and submitting issues like this. Disclaimer: I'm not an official OpenLDAP project member and I'm not an expert for this CVE-ID process. >From my understanding you can request a CVE-ID which is kept confidential until the vendor developed a fix. This is useful to already have a unique reference for all the work done upstream to fix a particular security issue and for applying back-port patches to downstream packages (e.g. in Linux distributions). Furthermore OpenLDAP's ITS allows to mark an issue as security issue which hides it from public access. I read Howard's comment that he meant exactly this. Ciao, Michael.

1 0

Re: (ITS#9124) CVE-ID?
by stephan＠srlabs.de 10 Jan '20

10 Jan '20

--_000_e1c562ac33aa2ed6c8e93818cf4da3fasrlabsde_ Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: base64 SGkgTWljaGFlbCDigJQNCg0KU28gZmFyIEkgaGF2ZSBub3QgcmVxdWVzdGVkIGEgQ1ZFLUlkIGZv ciB0aGUgaXNzdWUuIFRoYXQncyB3aGF0IEhvd2FyZCB3cm90ZSBpbiB0aGlzIHJlZ2FyZDoNCg0K VXN1YWwgcHJhY3RpY2UgZm9yIENWRXMgaXMgbm90IHRvIG1ha2UgdGhlbSBwdWJsaWMgdW50aWwg Zml4ZXMgYXJlIHJlbGVhc2VkLiBJbg0KdGhlDQpmdXR1cmUsIHlvdSBzaG91bGQgdGljayB0aGUg TWFqb3IgU2VjdXJpdHkgSXNzdWUgYnV0dG9uIGZvciBwb3RlbnRpYWwgQ1ZFcyBzbw0KdGhleQ0K Y2FuIGJlIGhhbmRsZWQgcHJpdmF0ZWx5IGJlZm9yZSByZWxlYXNlLg0KDQoNCkkgYW0gbm90IGF3 YXJlIG9mIGEgcmVsZWFzZSBpbmNsdWRpbmcgdGhlIGJ1Z2ZpeCBmb3IgdGhlIGlzc3VlLiBJZiB0 aGUgcmVsZWFzZSBhbHJlYWR5IGV4aXN0cyBJIGFtIGhhcHB5IHRvIHJlcXVlc3QgYSBDVkUtSWQg Zm9yIGl0DQoNCkNoZWVycw0KDQogICAgLVN0ZXBoYW4NCg0KT24gMS8xMC8yMCAyOjA0IFBNLCBN aWNoYWVsIFN0csO2ZGVyIHdyb3RlOg0KDQpTdGVwaGFuLA0KDQpyZWdhcmRpbmc6DQoNCmh0dHBz Oi8vd3d3Lm9wZW5sZGFwLm9yZy9pdHMvaW5kZXguY2dpP2ZpbmRpZD05MTI0DQoNCldhcyB0aGVy ZSBldmVyIGEgQ1ZFLUlkIGFzc2lnbmVkIHRvIHRoaXMgaXNzdWU/IEknZCBsaWtlIHRvIHJlZmVy ZW5jZSBpdA0KaW4gYmFjay1wb3J0IHBhdGNoZXMgZm9yIGRvd25zdHJlYW0gcGFja2FnZXMuDQoN CkNpYW8sIE1pY2hhZWwuDQoNCg0K --_000_e1c562ac33aa2ed6c8e93818cf4da3fasrlabsde_ Content-Type: text/html; charset="utf-8" Content-ID: <53AC3735BCF1C94BAC7633E57FADE8D2(a)EURPRD10.PROD.OUTLOOK.COM> Content-Transfer-Encoding: base64 PGh0bWw+DQo8aGVhZD4NCjxtZXRhIGh0dHAtZXF1aXY9IkNvbnRlbnQtVHlwZSIgY29udGVudD0i dGV4dC9odG1sOyBjaGFyc2V0PXV0Zi04Ij4NCjwvaGVhZD4NCjxib2R5Pg0KPHA+SGkgTWljaGFl bCDigJQ8L3A+DQo8cD5TbyBmYXIgSSBoYXZlIG5vdCByZXF1ZXN0ZWQgYSBDVkUtSWQgZm9yIHRo ZSBpc3N1ZS4gVGhhdCdzIHdoYXQgSG93YXJkIHdyb3RlIGluIHRoaXMgcmVnYXJkOjxicj4NCjwv cD4NCjxwcmUgc3R5bGU9ImNvbG9yOiByZ2IoMCwgMCwgMCk7IGZvbnQtc3R5bGU6IG5vcm1hbDsg Zm9udC12YXJpYW50LWxpZ2F0dXJlczogbm9ybWFsOyBmb250LXZhcmlhbnQtY2Fwczogbm9ybWFs OyBmb250LXdlaWdodDogNDAwOyBsZXR0ZXItc3BhY2luZzogbm9ybWFsOyBvcnBoYW5zOiAyOyB0 ZXh0LWFsaWduOiBzdGFydDsgdGV4dC1pbmRlbnQ6IDBweDsgdGV4dC10cmFuc2Zvcm06IG5vbmU7 IHdpZG93czogMjsgd29yZC1zcGFjaW5nOiAwcHg7IC13ZWJraXQtdGV4dC1zdHJva2Utd2lkdGg6 IDBweDsgYmFja2dyb3VuZC1jb2xvcjogcmdiKDI1NSwgMjU1LCAyNTUpOyB0ZXh0LWRlY29yYXRp b24tc3R5bGU6IGluaXRpYWw7IHRleHQtZGVjb3JhdGlvbi1jb2xvcjogaW5pdGlhbDsiPjxibG9j a3F1b3RlIHR5cGU9ImNpdGUiPjxwcmUgc3R5bGU9ImNvbG9yOiByZ2IoMCwgMCwgMCk7IGZvbnQt c3R5bGU6IG5vcm1hbDsgZm9udC12YXJpYW50LWxpZ2F0dXJlczogbm9ybWFsOyBmb250LXZhcmlh bnQtY2Fwczogbm9ybWFsOyBmb250LXdlaWdodDogNDAwOyBsZXR0ZXItc3BhY2luZzogbm9ybWFs OyBvcnBoYW5zOiAyOyB0ZXh0LWFsaWduOiBzdGFydDsgdGV4dC1pbmRlbnQ6IDBweDsgdGV4dC10 cmFuc2Zvcm06IG5vbmU7IHdpZG93czogMjsgd29yZC1zcGFjaW5nOiAwcHg7IC13ZWJraXQtdGV4 dC1zdHJva2Utd2lkdGg6IDBweDsgYmFja2dyb3VuZC1jb2xvcjogcmdiKDI1NSwgMjU1LCAyNTUp OyB0ZXh0LWRlY29yYXRpb24tc3R5bGU6IGluaXRpYWw7IHRleHQtZGVjb3JhdGlvbi1jb2xvcjog aW5pdGlhbDsiPlVzdWFsIHByYWN0aWNlIGZvciBDVkVzIGlzIG5vdCB0byBtYWtlIHRoZW0gcHVi bGljIHVudGlsIGZpeGVzIGFyZSByZWxlYXNlZC4gSW4NCnRoZQ0KZnV0dXJlLCB5b3Ugc2hvdWxk IHRpY2sgdGhlIE1ham9yIFNlY3VyaXR5IElzc3VlIGJ1dHRvbiBmb3IgcG90ZW50aWFsIENWRXMg c28NCnRoZXkNCmNhbiBiZSBoYW5kbGVkIHByaXZhdGVseSBiZWZvcmUgcmVsZWFzZS4NCjwvcHJl PjwvYmxvY2txdW90ZT48L3ByZT4NCjxkaXYgY2xhc3M9Im1vei1jaXRlLXByZWZpeCI+SSBhbSBu b3QgYXdhcmUgb2YgYSByZWxlYXNlIGluY2x1ZGluZyB0aGUgYnVnZml4IGZvciB0aGUgaXNzdWUu IElmIHRoZSByZWxlYXNlIGFscmVhZHkgZXhpc3RzIEkgYW0gaGFwcHkgdG8gcmVxdWVzdCBhIENW RS1JZCBmb3IgaXQ8L2Rpdj4NCjxkaXYgY2xhc3M9Im1vei1jaXRlLXByZWZpeCI+PGJyPg0KPC9k aXY+DQo8ZGl2IGNsYXNzPSJtb3otY2l0ZS1wcmVmaXgiPkNoZWVyczwvZGl2Pg0KPGRpdiBjbGFz cz0ibW96LWNpdGUtcHJlZml4Ij48YnI+DQo8L2Rpdj4NCjxkaXYgY2xhc3M9Im1vei1jaXRlLXBy ZWZpeCI+Jm5ic3A7Jm5ic3A7Jm5ic3A7IC1TdGVwaGFuPGJyPg0KPC9kaXY+DQo8ZGl2IGNsYXNz PSJtb3otY2l0ZS1wcmVmaXgiPjxicj4NCjwvZGl2Pg0KPGRpdiBjbGFzcz0ibW96LWNpdGUtcHJl Zml4Ij5PbiAxLzEwLzIwIDI6MDQgUE0sIE1pY2hhZWwgU3Ryw7ZkZXIgd3JvdGU6PGJyPg0KPC9k aXY+DQo8YmxvY2txdW90ZSB0eXBlPSJjaXRlIiBjaXRlPSJtaWQ6MDA5YTgyNTgtZTgxNC1iYTI0 LTliYTktN2UyNDg0OTk3ZTRkQHN0cm9lZGVyLmNvbSI+DQo8cHJlIGNsYXNzPSJtb3otcXVvdGUt cHJlIiB3cmFwPSIiPlN0ZXBoYW4sDQoNCnJlZ2FyZGluZzoNCg0KPGEgY2xhc3M9Im1vei10eHQt bGluay1mcmVldGV4dCIgaHJlZj0iaHR0cHM6Ly93d3cub3BlbmxkYXAub3JnL2l0cy9pbmRleC5j Z2k/ZmluZGlkPTkxMjQiPmh0dHBzOi8vd3d3Lm9wZW5sZGFwLm9yZy9pdHMvaW5kZXguY2dpP2Zp bmRpZD05MTI0PC9hPg0KDQpXYXMgdGhlcmUgZXZlciBhIENWRS1JZCBhc3NpZ25lZCB0byB0aGlz IGlzc3VlPyBJJ2QgbGlrZSB0byByZWZlcmVuY2UgaXQNCmluIGJhY2stcG9ydCBwYXRjaGVzIGZv ciBkb3duc3RyZWFtIHBhY2thZ2VzLg0KDQpDaWFvLCBNaWNoYWVsLg0KDQo8L3ByZT4NCjwvYmxv Y2txdW90ZT4NCjwvYm9keT4NCjwvaHRtbD4NCg== --_000_e1c562ac33aa2ed6c8e93818cf4da3fasrlabsde_--

1 0

Re: (ITS#9124) CVE-ID?
by michael＠stroeder.com 10 Jan '20

10 Jan '20

Stephan, regarding: https://www.openldap.org/its/index.cgi?findid=9124 Was there ever a CVE-Id assigned to this issue? I'd like to reference it in back-port patches for downstream packages. Ciao, Michael.

1 0

Re: (ITS#9098) assert fails in meta_back_search in some cases after reconnect
by maxime.besson＠worteks.com 10 Jan '20

10 Jan '20

Hi, After a couple of months without any issues using 2.4.48, we suddenly encountered a crash again, but this time on 2.4.48. It was the exact same symptom, and the same assert failing as in my original message. It appears that the issue happens a lot more rarely in 2.4.48 compared to 2.4.47, so ITS#8841 possibly had an effect on my issue, but did not solve it completely. I have a core dump I can run tests against, if you need. -- Maxime Besson Expert Infrastructure - Worteks maxime.besson(a)worteks.com

1 0

(ITS#9150) olcDbNoSync: FALSE has the same effect as olcDbNoSync: TRUE
by maxime.besson＠worteks.com 09 Jan '20

09 Jan '20

Full_Name: Maxime Besson Version: 2.4.48 OS: Debian Buster / CentOS7 URL: ftp://ftp.openldap.org/incoming/ Submission from: (NULL) (2a01:cb00:802:8400:2cbe:3c60:fca6:e50b) While migrating configuration from slapd.conf to cn=config, I noticed something pretty strange related to the dbnosync option The result of converting the following config: include ./core.schema pidfile ./slapd.1.pid argsfile ./slapd.1.args database mdb suffix "dc=example,dc=com" rootdn "cn=Manager,dc=example,dc=com" rootpw secret directory db.1.a index objectClass eq index cn,sn,uid pres,eq,sub index entryUUID,entryCSN eq Is (only interested in MDB config): # AUTO-GENERATED FILE - DO NOT EDIT!! Use ldapmodify. # CRC32 3df9c3d6 dn: olcDatabase={1}mdb objectClass: olcDatabaseConfig objectClass: olcMdbConfig olcDatabase: {1}mdb olcSuffix: dc=example,dc=com olcAddContentAcl: FALSE olcLastMod: TRUE olcMaxDerefDepth: 15 olcReadOnly: FALSE olcRootDN: cn=Manager,dc=example,dc=com olcRootPW:: c2VjcmV0 olcSyncUseSubentry: FALSE olcMonitoring: TRUE olcDbDirectory: db.1.a olcDbNoSync: FALSE olcDbIndex: objectClass eq olcDbIndex: entryUUID eq olcDbIndex: entryCSN eq olcDbIndex: cn pres,eq,sub olcDbIndex: uid pres,eq,sub olcDbIndex: sn pres,eq,sub olcDbMaxReaders: 0 olcDbMaxSize: 10485760 olcDbMode: 0600 olcDbSearchStack: 16 olcDbMaxEntrySize: 0 olcDbRtxnSize: 10000 As you can see, olcDbNoSync has the value FALSE, because there was no "dbnosync" option in slapd.conf, however, performance testing shows a dramatic increase in write speed after slapd.d migration. Which seems odd to me. It seems like the MDB database was not syncing to disk anymore despite olcDbNoSync being FALSE Removing olcDbNoSync: FALSE from cn=config did restore previous performance and syncing behavior Looking at servers/slapd/back-mdb/config.c:723 I found this: case MDB_DBNOSYNC: if ( c->value_int ) mdb->mi_dbenv_flags |= MDB_NOSYNC; else mdb->mi_dbenv_flags ^= MDB_NOSYNC; The else case seems wrong, I replaced it with case MDB_DBNOSYNC: if ( c->value_int ) mdb->mi_dbenv_flags |= MDB_NOSYNC; else mdb->mi_dbenv_flags &= ~MDB_NOSYNC; And it solves the issue on my system. Reproduced on master, and 2.4.48, on Debian

1 0

Re: (ITS#9146) incomplete initialization of sessionlog structure may cause session log to grow indefinitely
by hyc＠symas.com 08 Jan '20

08 Jan '20

maxime.besson(a)worteks.com wrote: > Full_Name: Maxime Besson > Version: 2.4.48 > OS: Amazon Linux > URL: ftp://ftp.openldap.org/incoming/ > Submission from: (NULL) (92.184.104.114) Thanks for the report, fixed now in git master. > > > During a cloud provider migration, I have migrated an OpenLDAP instance using > MDB + Syncrepl (in mirror mode, with session log) from Ubuntu to Amazon Linux. > > When starting a server with no data, syncrepl kicks in and starts replicating > the other server's database (12G, 7M entries). > > In Ubuntu this phase takes about 25 minutes (with dbnosync). In Amazon Linux, > with the exact same cn=config and daemon options, it took 10 days on first try, > at 100% CPU consumption the whole time. > > I observed that the start of the import is pretty fast (data.mdb grows by > 10M/s) but import speed slows down rapidly to a crawl. > > After some investigation, I discovered that disabling the sessionlog brings the > import times to normal. > > Digging further, I found that most of the CPU time is spent in > syncprov_add_slog, and particularly this line: > > > /* Keep the list in csn order. */ > ... > for ( sep = &sl->sl_head; *sep; sep = &(*sep)->se_next ) { >>>>>>>> if ( ber_bvcmp( &se->se_csn, &(*sep)->se_csn ) < 0 ) { > se->se_next = *sep; > *sep = se; > break; > } > } > > The sessionlog appears to be growing endlessly: > > (gdb) print sl->sl_num > $1 = 681896 > (gdb) print sl->sl_size > $3 = 100 > > Digging around the source, it seems that the session log is supposed to be > cleaned up at the end of syncprov_add_slog, if it's not playing: > > if (!sl->sl_playing) { > while ( sl->sl_num > sl->sl_size ) { > ... > > However: > > (gdb) print sl->sl_playing > $4 = 543388517 > > This looked like an uninitialized value to me, and indeed, sp_cf_gen > doesn't seem to initialize this field: > > if ( !sl ) { > sl = ch_malloc( sizeof( sessionlog )); > sl->sl_mincsn = NULL; > sl->sl_sids = NULL; > sl->sl_num = 0; > sl->sl_numcsns = 0; > sl->sl_head = sl->sl_tail = NULL; > ldap_pvt_thread_mutex_init( &sl->sl_mutex ); > si->si_logs = sl; > } > > > I tried the following patch: > > --- openldap-2.4.48.orig/servers/slapd/overlays/syncprov.c 2019-07-23 > 16:46:22.000000000 +0200 > +++ openldap-2.4.48/servers/slapd/overlays/syncprov.c 2020-01-08 > 11:33:16.770110282 +0100 > @@ -3082,6 +3082,7 @@ > sl = ch_malloc( sizeof( sessionlog )); > sl->sl_mincsn = NULL; > sl->sl_sids = NULL; > + sl->sl_playing = 0; > sl->sl_num = 0; > sl->sl_numcsns = 0; > sl->sl_head = sl->sl_tail = NULL; > > > And it got rid of the issue. My guess is that most of the time, sl_playing > happens to be 0, but on Amazon Linux, for some reason (patched glibc?), the > sessionlog lands in the wrong chunk of uninitilized memory > > Additional info: > > # rpm -q glibc > glibc-2.26-32.amzn2.0.2.x86_64 > > # uname -a > Linux 4.14.152-127.182.amzn2.x86_64 #1 SMP Thu Nov 14 17:32:43 UTC 2019 x86_64 > x86_64 x86_64 GNU/Linux > > # /usr/local/openldap/libexec/slapd -V > @(#) $OpenLDAP: slapd 2.4.48 (Jan 8 2020 11:39:38) $ > > (LTB build) > > > > > -- -- 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#9147) syncrepl connexion leak when provider uses an expired certificate
by maxime.besson＠worteks.com 08 Jan '20

08 Jan '20

Full_Name: Maxime Besson Version: 2.4.48 OS: Debian Buster / CentOS7 URL: https://cloud.worteks.com/index.php/s/9CE6ALLaAfrxZW4/download Submission from: (NULL) (92.184.104.113) I have two OpenLDAP (2.4.48, Ubuntu) servers running with syncrepl in mirrormode. One of my server's X509 certificates has recently expired, and I noticed that while it was expired, the other node's connection count kept climbing until it a "Max open files" condition. It seems that when a Syncrepl consumer encounters a certificate error, the outgoing LDAP connection to the provider is never closed. Attached to this bug you will find a test case to reproduce this behavior # runs a provider with a bogus certificate # and a consumer with retry=3+ sh test.sh ... TLS certificate verification: Error, self signed certificate TLS trace: SSL3 alert write:fatal:unknown CA TLS trace: SSL_connect:error in error TLS: can't connect: error:1416F086:SSL routines:tls_process_server_certificate:certificate verify failed (self signed certificate). 5e160966 slap_client_connect: URI=ldaps://127.0.1.1:6636/ DN="cn=manager,dc=example,dc=com" ldap_sasl_bind_s failed (-1) 5e160966 do_syncrepl: rid=001 rc -1 retrying ... and so on, every 3 seconds While the consumer retries, running lsof on its PID will reveal the connection leak: 42u TCP localhost:45964->localhost.lan:6636 (CLOSE_WAIT) 43u TCP localhost:45966->localhost.lan:6636 (CLOSE_WAIT) 44u TCP localhost:45968->localhost.lan:6636 (CLOSE_WAIT) 45u TCP localhost:45970->localhost.lan:6636 (CLOSE_WAIT) 46u TCP localhost:45972->localhost.lan:6636 (CLOSE_WAIT) 47u TCP localhost:45974->localhost.lan:6636 (CLOSE_WAIT) 48u TCP localhost:45976->localhost.lan:6636 (CLOSE_WAIT) 49u TCP localhost:45978->localhost.lan:6636 (CLOSE_WAIT) 50u TCP localhost:45980->localhost.lan:6636 (CLOSE_WAIT) 51u TCP localhost:45982->localhost.lan:6636 (CLOSE_WAIT) 52u TCP localhost:45984->localhost.lan:6636 (CLOSE_WAIT) 53u TCP localhost:45986->localhost.lan:6636 (CLOSE_WAIT) 54u TCP localhost:45988->localhost.lan:6636 (CLOSE_WAIT) 55u TCP localhost:45990->localhost.lan:6636 (CLOSE_WAIT) 56u TCP localhost:45992->localhost.lan:6636 (CLOSE_WAIT) 57u TCP localhost:45994->localhost.lan:6636 (CLOSE_WAIT) 58u TCP localhost:45996->localhost.lan:6636 (CLOSE_WAIT) 59u TCP localhost:45998->localhost.lan:6636 (CLOSE_WAIT) 60u TCP localhost:46000->localhost.lan:6636 (CLOSE_WAIT) 61u TCP localhost:46002->localhost.lan:6636 (CLOSE_WAIT) 62u TCP localhost:46004->localhost.lan:6636 (CLOSE_WAIT) 63u TCP localhost:46006->localhost.lan:6636 (CLOSE_WAIT) 64u TCP localhost:46008->localhost.lan:6636 (CLOSE_WAIT) Modifying the provider URL in slapd.2.conf with a wrong port causes the syncrepl consumer to fail and retry just as much, but without connection piling up in CLOSE_WAIT state. This is not a very critical issue because it only affects servers who are in already degraded condition (broken replication, invalid certificate on the provider) but I thought it still was worth reporting. I was able to reproduce this issue on the git master branch, on released 2.4.48, on Centos7 and on Debian Buster. OpenSSL version on the debian system: 1.1.1d-0+deb10u2

1 0

(ITS#9146) incomplete initialization of sessionlog structure may cause session log to grow indefinitely
by maxime.besson＠worteks.com 08 Jan '20

08 Jan '20

Full_Name: Maxime Besson Version: 2.4.48 OS: Amazon Linux URL: ftp://ftp.openldap.org/incoming/ Submission from: (NULL) (92.184.104.114) During a cloud provider migration, I have migrated an OpenLDAP instance using MDB + Syncrepl (in mirror mode, with session log) from Ubuntu to Amazon Linux. When starting a server with no data, syncrepl kicks in and starts replicating the other server's database (12G, 7M entries). In Ubuntu this phase takes about 25 minutes (with dbnosync). In Amazon Linux, with the exact same cn=config and daemon options, it took 10 days on first try, at 100% CPU consumption the whole time. I observed that the start of the import is pretty fast (data.mdb grows by 10M/s) but import speed slows down rapidly to a crawl. After some investigation, I discovered that disabling the sessionlog brings the import times to normal. Digging further, I found that most of the CPU time is spent in syncprov_add_slog, and particularly this line: /* Keep the list in csn order. */ ... for ( sep = &sl->sl_head; *sep; sep = &(*sep)->se_next ) { >>>>>>> if ( ber_bvcmp( &se->se_csn, &(*sep)->se_csn ) < 0 ) { se->se_next = *sep; *sep = se; break; } } The sessionlog appears to be growing endlessly: (gdb) print sl->sl_num $1 = 681896 (gdb) print sl->sl_size $3 = 100 Digging around the source, it seems that the session log is supposed to be cleaned up at the end of syncprov_add_slog, if it's not playing: if (!sl->sl_playing) { while ( sl->sl_num > sl->sl_size ) { ... However: (gdb) print sl->sl_playing $4 = 543388517 This looked like an uninitialized value to me, and indeed, sp_cf_gen doesn't seem to initialize this field: if ( !sl ) { sl = ch_malloc( sizeof( sessionlog )); sl->sl_mincsn = NULL; sl->sl_sids = NULL; sl->sl_num = 0; sl->sl_numcsns = 0; sl->sl_head = sl->sl_tail = NULL; ldap_pvt_thread_mutex_init( &sl->sl_mutex ); si->si_logs = sl; } I tried the following patch: --- openldap-2.4.48.orig/servers/slapd/overlays/syncprov.c 2019-07-23 16:46:22.000000000 +0200 +++ openldap-2.4.48/servers/slapd/overlays/syncprov.c 2020-01-08 11:33:16.770110282 +0100 @@ -3082,6 +3082,7 @@ sl = ch_malloc( sizeof( sessionlog )); sl->sl_mincsn = NULL; sl->sl_sids = NULL; + sl->sl_playing = 0; sl->sl_num = 0; sl->sl_numcsns = 0; sl->sl_head = sl->sl_tail = NULL; And it got rid of the issue. My guess is that most of the time, sl_playing happens to be 0, but on Amazon Linux, for some reason (patched glibc?), the sessionlog lands in the wrong chunk of uninitilized memory Additional info: # rpm -q glibc glibc-2.26-32.amzn2.0.2.x86_64 # uname -a Linux 4.14.152-127.182.amzn2.x86_64 #1 SMP Thu Nov 14 17:32:43 UTC 2019 x86_64 x86_64 x86_64 GNU/Linux # /usr/local/openldap/libexec/slapd -V @(#) $OpenLDAP: slapd 2.4.48 (Jan 8 2020 11:39:38) $ (LTB build)

1 0

Re: (ITS#6104) race condition with cancel operation
by ondra＠mistotebe.net 03 Jan '20

03 Jan '20

This might be related or the same issue. With ITS#9124 and ITS#9145 fixed, if you run: ldapsearch -E '!sync=rp' -E '!cancel' syncprov has freed the operation and cancel_extop() still tries to touch the same Operation pointer without checking it's still in the connection list. At least valgrind isn't happy. -- 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#9145) ldap tools try to attach configured controls to cancel/abandon operations
by ondra＠openldap.org 03 Jan '20

03 Jan '20

Full_Name: Ondrej Kuznik Version: re24/master OS: URL: Submission from: (NULL) (146.90.154.72) Take this command for example: ldapsearch -E '!sync=rp' -E '!cancel' Here, tool_check_abandon() calls ldap_cancel_s() with sctrls == NULL, but ld->ld_sctrls contains the syncrepl control as a default so it gets used instead, same for abandon. This means the option is broken. tool_check_abandon() should pass an zero-length LDAPControl list instead. Patch coming shortly.

1 0

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

1 0

2025

2024

2023

2022

2021

2020

2019

2018

2017

2016

2015

2014

2013

2012

2011

2010

2009

2008

2007

2006

openldap-bugs