openldap-bugs

openldap-bugs@openldap.org

1 participants
21065 discussions

(ITS#8211) ssf does not reflect actual security of connection
by hkario＠redhat.com 03 Aug '15

03 Aug '15

Full_Name: Hubert Kario Version: all OS: Linux URL: Submission from: (NULL) (213.175.37.10) Section "14.2.1. Security Strength Factors"[1] states "A SSF greater than one (>1) roughly correlates to the effective encryption key length.". This is not the case more often than not. Problem is that ssf as it is calculated now doesn't take into consideration all the cryptographic primitives in use. In other words, a connection that uses a 512 bit RSA certificates and negotiates TLS_RSA_WITH_AES_128_CBC_SHA (AES256-SHA) certainly does not provide security equivalent to "modern strong ciphers"[2][3] and should be awarded "256". Similarly a connection that uses 512 bit DH parameters and negotiates TLS_DHE_RSA_WITH_AES_256_CBC_SHA (DHE-RSA-AES256-SHA) does not provide security that should be awarded "256"[5]. In fact, recommending use of high key sizes[2] will cause the connection to use _less_ secure CBC ciphersuites[5] with clients that support AEAD ciphersuites with AES-128 only (like Thunderbird and Firefox do). Section 8.4.9[2] also calls RC4 a "modern strong cipher", most cryptographers disagree[6]. So I think either: 1). ssf needs to be redefined to consider any value higher that "2" to be equal, and requiring the server administrators to enable only ciphersuites they consider secure, or 2). the whole code that calculates ssf needs to be updated to take into account many more things: * use of AEAD * use of Encrypt-then-MAC * the protocol version used (both because TLS1.0 specific attacks[7] as wewell as the use of SHA1+MD5 for signatures which limits the connection security to 80 bits[8] (optimistically) if client certificates are in use in TLS < 1.2) * encryption algorithm on session tickets * current state of attacks on a given ciphersuite * the size of ECDHE curve, FFDHE prime or server certificate key size, depending on ciphersuite negotiated * the signature algorithm used in Certificate Verify message * the key size of client certificate * the signature on the client certificate and key sizes in CA certificates * the HMAC used * key size of the symmetric cipher * (probably other things I didn't think about) 1 - http://www.openldap.org/doc/admin24/security.html 2 - http://w.w.openldap.org/doc/admin24/access-control.html section 8.4.9 3 - https://freakattack.com/ 4 - https://weakdh.org/ 5 - http://www.isg.rhul.ac.uk/tls/Lucky13.html 6 - https://tools.ietf.org/html/rfc7465 7 - https://en.wikipedia.org/wiki/Transport_Layer_Security#BEAST_attack 8 - https://www.iacr.org/cryptodb/archive/2004/CRYPTO/1472/1472.pdf

1 0

Re: (ITS#8209) Broken MDB_CP_COMPACT threading
by h.b.furuseth＠usit.uio.no 03 Aug '15

03 Aug '15

Okay, that was one confused ITS in response to equally confused code. Trying again. Draft fixes in my updated branch "mdb/copyfd1" (non-fast-forward). It's broken if mdb_env_copythr() has a write error: * copyfd1 can (A) overrun buffer mc_wlen, and (B) hang, if if cthr_toggle() is in cond_wait() when the error occurs: It sets mc_new and returns success. cwalk() proceeds to write at mc_wbuf+mc_wlen, but copythr() did not reset mc_wlen. Then copyfd1() waits for the now-dead copythr() to clear mc_new. Fixes: (A) join the if(mc_status) and while(mc_new==1) in cthr_toggle. (B) Drop the wait before THREAD_FINISH(), it seems pointless. Both Posix and Windows doc say that THREAD_FINISH waits. Or if Windows needs it for some reason, then copythr must live until it receives mc_new=-1, so it can set mc_new=0. * copyfd1() loses any error from the final cthr_toggle(). Fix: Return rc ? rc : my.mc_status. Tested on Linux with fake write errors, with/without fixes. While not a bug, I also see no point in both threads' initial waits. copyfd1() can own the buffer initially (set mc_new=0). I'm guessing the waits are there because the code tries to guide the threads from step to step, but it broke because you didn't think of every possibility. It's easier to define and maintain one cond_wait state per thread and keep things consistent there. More on error checking: copyfd1() omits most error checking and the cleanup after errors. E.g. it does not tell copythr to finish if txn_begin fails. Each thread is slow to react to errors in the other thread. I/O will cease quicker if both threads set and check mc_status. If so, mc_status can no longer be part of the cond_wait condition, since it won't be mutex-protected. So the threads might chat a bit more before finishing. I'd rename mc_status -> mc_error. "while (!my->mc_error && ...)" is quite self-explanatory, unlike "while (!my->mc_status && ...)". About lock/unlock outside vs. inside the loop: When outside, copythr() must block for the threads to exchange buffers. When inside, the slowest thread does not block, but there are more lock/unlock/wait calls. Testing: Locks inside is clearly faster on tmpfs. On a regular FS I don't know - it may have been a bit slower, but times varied more than the difference. Finally, cwalk() could re-use the page buffers it mallocs. -- Hallvard

1 0

(ITS#8210) slapd-sock: second subsequent bind fails
by michael＠stroeder.com 01 Aug '15

01 Aug '15

Full_Name: Version: OS: URL: Submission from: (NULL) (79.223.48.67) When using *one* connection for sending *two* sequential bind requests slapd-sock blocks. I have a working test case which I can send upon request.

1 0

Re: (ITS#8207) ppolicy: pwdMinLength not checked if pwdInHistory == 0
by michael＠stroeder.com 01 Aug '15

01 Aug '15

IanB wrote: > I've attempted to test with OpenLDAP 2.4.41 but cannot get password changing > to work at all, constantly getting error: "passwd: Authentication token > manipulation error" Greping through the source this message is output from slapo-nssov. Are you sure that you re-built and installed slapo-nssov from 2.4.41? Also you should always first test with ldappasswd command-line tool to avoid false interaction with other software. What else do you have configured? > Unfortunately, I cannot spend more time on this now. What does that mean? If you don't want to work on this ITS any further it's probably the best to close it. Ciao, Michael.

1 0

Re: (ITS#8207) ppolicy: pwdMinLength not checked if pwdInHistory == 0
by porjo38＠yahoo.com.au 01 Aug '15

01 Aug '15

I've attempted to test with OpenLDAP 2.4.41 but cannot get password changing to work at all, constantly getting error: "passwd: Authentication token manipulation error" Unfortunately, I cannot spend more time on this now. On 30/07/15 03:01, Michael Ströder wrote: > porjo38(a)yahoo.com.au wrote: >> Using password policy overlay, pwdMinLength is not checked when pwdInHistory == >> 0. > > I tried to reproduce this with my local OpenLDAP 2.4.41 installation. > In one case I thought to see this but I could not reproduce all the time. > Maybe there's another condition for this to happen. > > Could you please also test with release 2.4.41? > > And please also post the entry with the password (and relevant pwd* attrs) and > the pwdPolicy entry used, both as LDIF (minus sensitive data). > > Ciao, Michael. >

1 0

Re: (ITS#8181) LMDB page leaks etc when treating DBs as data
by hyc＠symas.com 30 Jul '15

30 Jul '15

juerg.bircher(a)helmedica.com wrote: > --_000_D1E06B6B7E2juergbircherhelmedicacom_ > Content-Type: text/plain; charset="iso-8859-1" > Content-Transfer-Encoding: quoted-printable > > Hi Howard, > > I am new to lmdb. I have been working with lmdb intensively for one month. = > I really appreciate your great work. Good efficient C code is not always fo= > und! > Well I like to follow up on that reported issue. > I am using multiple databases on the same environment. I was a bit confused= > about your statement that most application use never subDBs? I think it is= > a great feature that helps to support multiple indexes. > I ran unintentionally into a related problem as I set the compare function = > for the main db to an integer based one opposite to the literal compare fun= > ction which is the default. Therefore when opening a database by its name t= > he wrong database might be returned as the integer compare function might t= > hink names are equal as only 96 bits (in my function) are compared. So the = > compare function only compares the prefix of the database names! > Maybe the database meta should be kept in a private space. But I also agree= > on your statement to keep things simple. I solved the problem by never usi= > ng the main db so under no circumstances the database meta is corrupted. I = > think the price paid for having only named databases is very cheap as I ope= > n databases at startup and keep the database index (dbi). Thanks for the feedback. Yes, this is the best practice - if you're using named databases, you should not use the main DB. (Or just make sure you don't create name collisions.) -- -- 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#8181) LMDB page leaks etc when treating DBs as data
by juerg.bircher＠helmedica.com 30 Jul '15

30 Jul '15

Sorry the mail before was not as plain text. Here again... Hi Howard, I am new to lmdb. I have been working with lmdb intensively for one month. I really appreciate your great work. Good efficient C code is not always found! Well I like to follow up on that reported issue. I am using multiple databases on the same environment. I was a bit confused about your statement that most application use never subDBs? I think it is a great feature that helps to support multiple indexes. I ran unintentionally into a related problem as I set the compare function for the main db to an integer based one opposite to the literal compare function which is the default. Therefore when opening a database by its name the wrong database might be returned as the integer compare function might think names are equal as only 96 bits (in my function) are compared. So the compare function only compares the prefix of the database names! Maybe the database meta should be kept in a private space. But I also agree on your statement to keep things simple. I solved the problem by never using the main db so under no circumstances the database meta is corrupted. I think the price paid for having only named databases is very cheap as I open databases at startup and keep the database index (dbi). Regards J=FCrg Rockethealth by Helmedica AG Web: www.rockethealth.ch J=FCrg Bircher Chief Technology Officer Mail: juerg.bircher(a)helmedica.ch

1 0

Re: (ITS#8181) LMDB page leaks etc when treating DBs as data
by juerg.bircher＠helmedica.com 30 Jul '15

30 Jul '15

--_000_D1E06B6B7E2juergbircherhelmedicacom_ Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable Hi Howard, I am new to lmdb. I have been working with lmdb intensively for one month. = I really appreciate your great work. Good efficient C code is not always fo= und! Well I like to follow up on that reported issue. I am using multiple databases on the same environment. I was a bit confused= about your statement that most application use never subDBs? I think it is= a great feature that helps to support multiple indexes. I ran unintentionally into a related problem as I set the compare function = for the main db to an integer based one opposite to the literal compare fun= ction which is the default. Therefore when opening a database by its name t= he wrong database might be returned as the integer compare function might t= hink names are equal as only 96 bits (in my function) are compared. So the = compare function only compares the prefix of the database names! Maybe the database meta should be kept in a private space. But I also agree= on your statement to keep things simple. I solved the problem by never usi= ng the main db so under no circumstances the database meta is corrupted. I = think the price paid for having only named databases is very cheap as I ope= n databases at startup and keep the database index (dbi). Regards J=FCrg Rockethealth by Helmedica AG Web: www.rockethealth.ch<http://www.rockethealth.ch/> J=FCrg Bircher Chief Technology Officer Mail: juerg.bircher(a)helmedica.ch<mailto:christoph.baumann@helmedica.ch> --_000_D1E06B6B7E2juergbircherhelmedicacom_ Content-Type: text/html; charset="iso-8859-1" Content-ID: <86943131EABB0349A4C3B75E01000508(a)eurprd03.prod.outlook.com> Content-Transfer-Encoding: quoted-printable <html> <head> <meta http-equiv=3D"Content-Type" content=3D"text/html; charset=3Diso-8859-= 1"> </head> <body style=3D"word-wrap: break-word; -webkit-nbsp-mode: space; -webkit-lin= e-break: after-white-space; color: rgb(0, 0, 0); font-size: 14px; font-fami= ly: Calibri, sans-serif;"> <div>Hi Howard,</div> <div><br> </div> <div>I am new to lmdb. I have been working with lmdb intensively for one mo= nth. I really appreciate your great work. Good efficient C code is not alwa= ys found! </div> <div>Well I like to follow up on that reported issue.</div> <div>I am using multiple databases on the same environment. I was a bit con= fused about your statement that most application use never subDBs? I think = it is a great feature that helps to support multiple indexes. </div> <div>I ran unintentionally into a related problem as I set the compare func= tion for the main db to an integer based one opposite to the literal compar= e function which is the default. Therefore when opening a database by its n= ame the wrong database might be returned as the integer compare function might think names are equal as on= ly 96 bits (in my function) are compared. So the compare function only comp= ares the prefix of the database names!</div> <div>Maybe the database meta should be kept in a private space. But I also = agree on your statement to keep things simple. I solved the problem by neve= r using the main db so under no circumstances the database meta is corrupte= d. I think the price paid for having only named databases is very cheap as I open databases at startup and keep= the database index (dbi).</div> <div><br> </div> <div>Regards</div> <div>J=FCrg</div> <div><br> </div> <p class=3D"MsoNormal" style=3D"margin: 0cm 0cm 0.0001pt; font-size: 11pt; = line-height: 11pt;"> <b><span lang=3D"EN-US" style=3D"font-size: 9pt; color: rgb(139, 141, 141);= font-family: 'FS Joey Medium';">Rockethealth by Helmedica AG<o:p></o:p></s= pan></b></p> <p class=3D"MsoNormal" style=3D"margin: 0cm 0cm 0.0001pt; font-size: 11pt;"= ><span lang=3D"EN-US" style=3D"font-size: 9pt; color: gray;">Web</span><spa= n lang=3D"EN-US" style=3D"font-size: 9pt; color: rgb(31, 73, 125);">: = </span><span style=3D"font-size: 9pt; color: rgb(31, 73, 125);"><a href=3D"= http://www.rockethealth.ch/" style=3D"color: rgb(149, 79, 114);"><span lang= =3D"EN-US" style=3D"color: blue;">www.rockethealth.ch</span></a></span><spa= n style=3D"font-size: 9pt; color: rgb(31, 73, 125);"></span><span lang=3D"E= N-US" style=3D"color: rgb(31, 73, 125);"><o:p></o:p></span></p> <p class=3D"MsoNormal" style=3D"margin: 0cm 0cm 0.0001pt; font-size: 11pt;"= ><span lang=3D"EN-US" style=3D"font-size: 9pt; color: gray;">J=FCrg Bircher= </span></p> <p class=3D"MsoNormal" style=3D"margin: 0cm 0cm 0.0001pt; font-size: 11pt;"= ><span style=3D"color: gray; font-size: 9pt;">Chief Technology </span>= <span style=3D"color: rgb(128, 128, 128); font-size: 12px;">Officer</span><= /p> <p class=3D"MsoNormal" style=3D"margin: 0cm 0cm 0.0001pt; font-size: 11pt;"= ><span lang=3D"EN-US" style=3D"font-size: 9pt; color: gray;">Mail: </s= pan><span style=3D"font-size: 9pt; color: rgb(31, 73, 125);"><a href=3D"mai= lto:christoph.baumann@helmedica.ch" style=3D"color: rgb(149, 79, 114);"><sp= an lang=3D"EN-US" style=3D"color: blue;">juerg.bircher(a)helmedica.ch</span><= /a></span><span lang=3D"EN-US" style=3D"color: rgb(31, 73, 125);"><o:p></o:= p></span></p> <p class=3D"MsoNormal" style=3D"margin: 0cm 0cm 0.0001pt; font-size: 11pt;"= ><span style=3D"color: gray; font-size: 11pt;"> </span><span style=3D"= font-size: 14px;"> </span></p> </body> </html> --_000_D1E06B6B7E2juergbircherhelmedicacom_--

1 0

Re: (ITS#8207) ppolicy: pwdMinLength not checked if pwdInHistory == 0
by porjo38＠yahoo.com.au 29 Jul '15

29 Jul '15

Thanks, I will try with 2.4.41 and let you know. I may not get a chance to test until this weekend. Relevant output from slapcat: dn: uid=ian,ou=UserAccounts,o=cwa objectClass: posixAccount objectClass: top objectClass: inetOrgPerson objectClass: ldapPublicKey givenName: Ian displayName: Ian Bishop uid: ian homeDirectory: /home/ian loginShell: /bin/bash cn: Ian Bishop structuralObjectClass: inetOrgPerson entryUUID: 767c952c-c867-1034-933d-53d15af42765 creatorsName: cn=admin,o=cwa createTimestamp: 20150727045535Z gidNumber: 1000 sn: Bishop uidNumber: 10000 userPassword:: xxxxxxxxxxxxxxxxxxxxxxxxxxxxxx pwdChangedTime: 20150729140556Z pwdHistory: 20150729140556Z#1.3.6.1.4.1.1466.115.121.1.40#38#{SSHA}xxxxxxxxxx entryCSN: 20150729140556.659729Z#000000#000#000000 modifiersName: cn=admin,o=cwa modifyTimestamp: 20150729140556Z dn: cn=passwordDefault,ou=policies,o=cwa objectClass: pwdPolicy objectClass: person objectClass: top cn: passwordDefault sn: passwordDefault pwdAttribute: userPassword pwdCheckQuality: 0 pwdMinAge: 0 pwdMaxAge: 0 pwdMaxFailure: 3 pwdFailureCountInterval: 0 pwdLockout: TRUE pwdAllowUserChange: TRUE pwdExpireWarning: 0 pwdGraceAuthNLimit: 0 pwdMustChange: FALSE pwdSafeModify: TRUE structuralObjectClass: person entryUUID: 3314dc02-ca3f-1034-825a-9d42205b22be creatorsName: cn=config createTimestamp: 20150729131225Z pwdMinLength: 6 pwdLockoutDuration: 300 pwdInHistory: 1 entryCSN: 20150729135535.164545Z#000000#000#000000 modifiersName: cn=admin,o=cwa modifyTimestamp: 20150729135535Z On 30/07/15 03:01, Michael Ströder wrote: > porjo38(a)yahoo.com.au wrote: >> Using password policy overlay, pwdMinLength is not checked when pwdInHistory == >> 0. > > I tried to reproduce this with my local OpenLDAP 2.4.41 installation. > In one case I thought to see this but I could not reproduce all the time. > Maybe there's another condition for this to happen. > > Could you please also test with release 2.4.41? > > And please also post the entry with the password (and relevant pwd* attrs) and > the pwdPolicy entry used, both as LDIF (minus sensitive data). > > Ciao, Michael. >

1 0

Re: (ITS#8209) Broken MDB_CP_COMPACT threading
by h.b.furuseth＠usit.uio.no 29 Jul '15

29 Jul '15

On 29/07/15 21:25, h.b.furuseth(a)usit.uio.no wrote: > (...)And copythr should set mc_new=0 before exiting also when setting > mc_status. so copyfd1 won't just sit and wait. I forgot it clears mc_new before setting mc_status. It's if it didn't keep the mutex it would have to set mc_new afterwards (after locking the mutex).

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