openldap-bugs

openldap-bugs@openldap.org

1 participants
21001 discussions

(ITS#9127) memory leak in mdb_entry_decode()
by grapvar＠gmail.com 02 Dec '19

02 Dec '19

Full_Name: Konstantin Andreev Version: 2.4.48 OS: Solaris 11.3 x64 URL: Submission from: (NULL) (79.135.238.172) servers/slapd/back-mdb/id2entry.c`mdb_entry_decode() leaks allocated [Entry] on error. Here is a fix for the master branch: --- a/servers/slapd/back-mdb/id2entry.c +++ b/servers/slapd/back-mdb/id2entry.c @@ -1130,8 +1130,12 @@ done: *e = x; rc = 0; -leave: +clr_mvc: if (mvc) mdb_cursor_close(mvc); return rc; +leave: + /* can't mdb_entry_return() because [Entry *x] init is incomplete */ + op->o_tmpfree( x, op->o_tmpmemctx ); + goto clr_mvc; } and for 2.4 branch, if you care: --- a/servers/slapd/back-mdb/id2entry.c +++ b/servers/slapd/back-mdb/id2entry.c @@ -695,12 +695,13 @@ if (i > mdb->mi_numads) { rc = mdb_ad_read(mdb, txn); if (rc) - return rc; + goto leave; if (i > mdb->mi_numads) { Debug( LDAP_DEBUG_ANY, "mdb_entry_decode: attribute index %d not recognized\n", i, 0, 0 ); - return LDAP_OTHER; + rc = LDAP_OTHER; + goto leave; } } a->a_desc = mdb->mi_ads[i]; @@ -745,7 +746,7 @@ Debug( LDAP_DEBUG_ANY, "mdb_entry_decode: attributeType %s value #%d provided more than once\n", a->a_desc->ad_cname.bv_val, j, 0 ); - return rc; + goto leave; } } a->a_next = a+1; @@ -758,4 +759,8 @@ 0, 0, 0 ); *e = x; return 0; +leave: + /* can't mdb_entry_return() because [Entry *x] init is incomplete */ + op->o_tmpfree( x, op->o_tmpmemctx ); + return rc; }

1 0

(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

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