openldap-bugs

openldap-bugs@openldap.org

1 participants
20967 discussions

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

05 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

Jump to page:

2025

2024

2023

2022

2021

2020

2019

2018

2017

2016

2015

2014

2013

2012

2011

2010

2009

2008

2007

2006

openldap-bugs