openldap-bugs December 2023

openldap-bugs@openldap.org

1 participants
90 discussions

[Issue 10144] New: Buffer overwrite in ldap_dn2bv_x
by openldap-its＠openldap.org 29 Jan '24

29 Jan '24

https://bugs.openldap.org/show_bug.cgi?id=10144 Issue ID: 10144 Summary: Buffer overwrite in ldap_dn2bv_x Product: OpenLDAP Version: 2.6.6 Hardware: All OS: All Status: UNCONFIRMED Keywords: needs_review Severity: normal Priority: --- Component: libraries Assignee: bugs(a)openldap.org Reporter: joshua(a)joshua.hu Target Milestone: --- Created attachment 995 --> https://bugs.openldap.org/attachment.cgi?id=995&action=edit ldap.c Hi there, While performing a security audit of openldap, I've discovered a buffer overwrite in the ldap_dn2bv_x function of libldap which can be triggered via an unauthenticated packet to slapd. The issue is specifically in this part oft he code: 3069 /* 3070 * trim the last ',' (the allocated memory 3071 * is one byte longer than required) 3072 */ 3073 bv->bv_len = len - 1; 3074 bv->bv_val[ bv->bv_len ] = '\0'; 'len' may be 0, therefore bv->bv_len becomes (unsigned long)-1 == 18446744073709551615, causing a one-byte buffer overwrite in bv->bv_len. It may be len when rdn2str returns 0: 3055 for ( l = 0, iRDN = 0; dn[ iRDN ]; iRDN++ ) { 3056 ber_len_t rdnl; 3057 3058 if ( rdn2str( dn[ iRDN ], &bv->bv_val[ l ], flags, 3059 &rdnl, sv2s ) ) { 3060 LDAP_FREEX( bv->bv_val, ctx ); 3061 bv->bv_val = NULL; 3062 goto return_results; 3063 } 3064 l += rdnl; 3065 } which it may do if 2571 static int 2572 rdn2str( LDAPRDN rdn, char *str, unsigned flags, ber_len_t *len, 2573 int ( *s2s ) ( struct berval *v, char * s, unsigned f, ber_len_t *l ) ) 2574 { 2575 int iAVA; 2576 ber_len_t l = 0; 2577 2578 for ( iAVA = 0; rdn[ iAVA ]; iAVA++ ) { [...] 2606 *len = l; 2607 2608 return( 0 ); 2609 } rdn[0] (i.e. dn[0][0]) is zero. There is already a check in ldap_dn2bv_x to ensure that there is not a null distinguished name, but no check for a null relative distinguished name: 3021 /* 3022 * a null dn means an empty dn string 3023 * FIXME: better raise an error? 3024 */ 3025 if ( dn == NULL || dn[0] == NULL ) { 3026 bv->bv_val = LDAP_STRDUPX( "", ctx ); 3027 return( LDAP_SUCCESS ); 3028 } This can be reproduced using the API and compiling with address sanitizer: clang -g -O0 -fsanitize=address -o ldap ldap.c -I/usr/local/include -L/usr/local/lib -Wl,-rpath=/usr/local/lib -lldap which crashes: ================================================================= ==2685861==ERROR: AddressSanitizer: heap-buffer-overflow on address 0x602000004c0f at pc 0x7ffff7ecae9d bp 0x7fffffff7390 sp 0x7fffffff7388 WRITE of size 1 at 0x602000004c0f thread T0 #0 0x7ffff7ecae9c in ldap_dn2bv_x /home/jrogers/openldap-clean/libraries/libldap/getdn.c:3074:28 #1 0x7ffff7f30135 in ldap_X509dn2bv /home/jrogers/openldap-clean/libraries/libldap/tls2.c:1686:7 #2 0x55555563000f in main /home/jrogers/ldap2.c:19:14 #3 0x7ffff7b25d8f (/lib/x86_64-linux-gnu/libc.so.6+0x29d8f) (BuildId: 203de0ae33b53fee1578b117cb4123e85d0534f0) #4 0x7ffff7b25e3f in __libc_start_main (/lib/x86_64-linux-gnu/libc.so.6+0x29e3f) (BuildId: 203de0ae33b53fee1578b117cb4123e85d0534f0) #5 0x555555572324 in _start (/home/jrogers/test+0x1e324) (BuildId: 5207fff637c8f2edc46784bf828dc09fddd34d85) 0x602000004c0f is located 1 bytes to the left of 1-byte region [0x602000004c10,0x602000004c11) allocated by thread T0 here: #0 0x5555555f516e in malloc (/home/jrogers/test+0xa116e) (BuildId: 5207fff637c8f2edc46784bf828dc09fddd34d85) #1 0x7ffff7ae8303 in ber_memalloc_x /home/jrogers/openldap-clean/libraries/liblber/memory.c:228:9 #2 0x7ffff7eca968 in ldap_dn2bv_x /home/jrogers/openldap-clean/libraries/libldap/getdn.c:3050:23 #3 0x7ffff7f30135 in ldap_X509dn2bv /home/jrogers/openldap-clean/libraries/libldap/tls2.c:1686:7 #4 0x55555563000f in main /home/jrogers/ldap2.c:19:14 #5 0x7ffff7b25d8f (/lib/x86_64-linux-gnu/libc.so.6+0x29d8f) (BuildId: 203de0ae33b53fee1578b117cb4123e85d0534f0) Alternatively you can send the following to a running slapd server: printf "MIIB5AIEMDAwMEqCATBPPTAwMDAwMDAwMDAwMDAwMDDvvrLvvrLvvrLvvrLvvrLvvrLvp7LvvrLvtrLvvrLvvrLvvrLvvrLvvrLvvrLvvrIsCgoKMi41LjQuMzk9MGswMDAGMDAwMDAwMAYxATEwMTAYGDAwMDAwMDAwMDAwMDAwMDAwMDAwMDAwMDA4XDAwMDAwMDAwMDAwMDAwMDAwMDAwMDAwMDAwMDAwMDAwMDAwMDAwMDAwMDAwMDAwMDAwMDAwMDAwMAMDMDAwMDAwMDAwMDAwMDAwMDAwMDAwMDAwMDAwMDAwMDAwMDAwMDAwMDAwMDAwMDAwMDAwMDAwMDAwMDAwMDAwMDAwMDAwMDAwMDAwMDAwMDAwMDAwMDAwMDAwMDAwMDAwMDAwMDAwMDAwMDAwMDAwMDAwMDAwMDAwMDAwMDAwMDAwMDAwMDAwMDAwMDAwMDAwMDAwMDAwMDAwMDAwMDAwMDAwMDAwMDAwMDAwMDAwMDAwMDAwMDAwMDAwMDAwMDAwMDAwMDAwMDAwMDAwMDAwMDAwMDAwMDAwMDAwMDAwMDAwMDAwMDAwMDAwMDAwMDAwMDAwMDAwMDAwMDAwMDAwMDAwMDAwMDAwMDAwMDAwMDAwMDAwMDAwMDAwMDAwMDA=" | base64 -d | nc localhost 389 which will exhibit the same behavior: ==1673381==ERROR: AddressSanitizer: heap-buffer-overflow on address 0x60200004c14f at pc 0x7ffff7ec0e9d bp 0x7fffb40c6e70 sp 0x7fffb40c6e68 WRITE of size 1 at 0x60200004c14f thread T2 [Detaching after fork from child process 3777333] #0 0x7ffff7ec0e9c in ldap_dn2bv_x /home/jrogers/openldap-clean/libraries/libldap/getdn.c:3074:28 #1 0x7ffff7f26135 in ldap_X509dn2bv /home/jrogers/openldap-clean/libraries/libldap/tls2.c:1686:7 #2 0x555555820765 in dnX509normalize (/usr/local/libexec/slapd+0x2cc765) (BuildId: 08ae5b20b8d2e527d77117f7cf2c8d26bd2a3707) #3 0x5555558e55a1 (/usr/local/libexec/slapd+0x3915a1) (BuildId: 08ae5b20b8d2e527d77117f7cf2c8d26bd2a3707) #4 0x555555819d06 (/usr/local/libexec/slapd+0x2c5d06) (BuildId: 08ae5b20b8d2e527d77117f7cf2c8d26bd2a3707) #5 0x5555558187b8 (/usr/local/libexec/slapd+0x2c47b8) (BuildId: 08ae5b20b8d2e527d77117f7cf2c8d26bd2a3707) #6 0x55555581c6de in dnPrettyNormal (/usr/local/libexec/slapd+0x2c86de) (BuildId: 08ae5b20b8d2e527d77117f7cf2c8d26bd2a3707) #7 0x555555835c95 in do_delete (/usr/local/libexec/slapd+0x2e1c95) (BuildId: 08ae5b20b8d2e527d77117f7cf2c8d26bd2a3707) #8 0x5555557a8ef5 (/usr/local/libexec/slapd+0x254ef5) (BuildId: 08ae5b20b8d2e527d77117f7cf2c8d26bd2a3707) #9 0x5555557a21f9 (/usr/local/libexec/slapd+0x24e1f9) (BuildId: 08ae5b20b8d2e527d77117f7cf2c8d26bd2a3707) #10 0x7ffff7f592c4 in ldap_int_thread_pool_wrapper /home/jrogers/openldap-clean/libraries/libldap/tpool.c:1059:3 #11 0x7ffff785eac2 (/lib/x86_64-linux-gnu/libc.so.6+0x94ac2) (BuildId: 203de0ae33b53fee1578b117cb4123e85d0534f0) #12 0x7ffff78f065f (/lib/x86_64-linux-gnu/libc.so.6+0x12665f) (BuildId: 203de0ae33b53fee1578b117cb4123e85d0534f0) -- You are receiving this mail because: You are on the CC list for the issue.

1 5

[Issue 10117] New: missing function declarations in slap-config.h
by openldap-its＠openldap.org 29 Jan '24

29 Jan '24

https://bugs.openldap.org/show_bug.cgi?id=10117 Issue ID: 10117 Summary: missing function declarations in slap-config.h Product: OpenLDAP Version: 2.6.6 Hardware: All OS: Windows Status: UNCONFIRMED Keywords: needs_review Severity: normal Priority: --- Component: build Assignee: bugs(a)openldap.org Reporter: mhardin(a)symas.com Target Milestone: --- Functions exported from slap-config.h need to be properly declared for Windows -- You are receiving this mail because: You are on the CC list for the issue.

1 6

[Issue 10074] New: lloadd: build broken with more recent versions of LLVM
by openldap-its＠openldap.org 29 Jan '24

29 Jan '24

https://bugs.openldap.org/show_bug.cgi?id=10074 Issue ID: 10074 Summary: lloadd: build broken with more recent versions of LLVM Product: OpenLDAP Version: 2.6.4 Hardware: All OS: FreeBSD Status: UNCONFIRMED Keywords: needs_review Severity: normal Priority: --- Component: lloadd Assignee: bugs(a)openldap.org Reporter: delphij(a)freebsd.org Target Milestone: --- There are two issues preventing lloadd from building with more recent versions of LLVM. These are discovered on FreeBSD but may affect other operating systems too. The first one is that ldap_pvt_thread_self is returning pthread_t (which is a pointer of struct pthread) on FreeBSD, but evthread_set_id_callback was expecting unsigned long. A possible solution would be to create a wrapper for the function, like: --- servers/lloadd/libevent_support.c.orig 2023-02-08 18:53:35 UTC +++ servers/lloadd/libevent_support.c @@ -131,6 +131,20 @@ lload_libevent_cond_timedwait( return ldap_pvt_thread_cond_wait( cond, mutex ); } +/* + * libevent2 expects the thread id has a type of unsigned long. + */ +static unsigned long +lload_libevent_thread_self(void) +{ + unsigned long retval; + static_assert(sizeof(ldap_pvt_thread_t) <= sizeof(unsigned long), + "ldap_pvt_thread_t has to be smaller or equal to unsigned long"); + + retval = (unsigned long)ldap_pvt_thread_self(); + return (retval); +} + int lload_libevent_init( void ) { @@ -152,7 +166,7 @@ lload_libevent_init( void ) evthread_set_lock_callbacks( &cbs ); evthread_set_condition_callbacks( &cond_cbs ); - evthread_set_id_callback( ldap_pvt_thread_self ); + evthread_set_id_callback( lload_libevent_thread_self ); return 0; } Or, maybe the code should just use evthread_use_pthreads() instead? (It's not very clear to me why we have the ldap_pvt_thread_self wrapper). Another issue is that module_init.c is trying to assign config_generic_wrapper to bi->bi_config: module_init.c:154:19: error: incompatible function pointer types assigning to 'BI_config *' (aka 'int (*)(struct BackendInfo *, const char *, int, int, char **)') from 'int (Backend *, const char *, int, int, char **)' (aka 'int (struct BackendDB *, const char *, int, int, char **)') [-Wincompatible-function-pointer-types] bi->bi_config = config_generic_wrapper; ^ ~~~~~~~~~~~~~~~~~~~~~~ For other backends, it's used as bi_db_config. It seems that I can set bi_config to NULL and bi_db_config to config_generic_wrapper, but it's not clear to me what the original intention was... -- You are receiving this mail because: You are on the CC list for the issue.

1 5

[Issue 10025] New: Add option to disable filtered searches for memberURL groups
by openldap-its＠openldap.org 29 Jan '24

29 Jan '24

https://bugs.openldap.org/show_bug.cgi?id=10025 Issue ID: 10025 Summary: Add option to disable filtered searches for memberURL groups Product: OpenLDAP Version: 2.5.14 Hardware: All OS: All Status: UNCONFIRMED Keywords: needs_review Severity: normal Priority: --- Component: overlays Assignee: bugs(a)openldap.org Reporter: subbarao(a)computer.org Target Milestone: --- One of the changes from 2.4 to 2.5 is that dynlist groups are now returned with (member=memberDN) searches. This is potentially appealing, but even with the ITS#9929 performance improvements, given the number of dynlist groups we have, search times are significantly impacted. We'd like to be able to cleanly disable this feature and exclude dynlist groups from (member=memberDN) filter consideration. The only way I've found so far is to patch the dynlist code itself. What I'm currently doing is adding a continue statement right above this line in dynlist_search(): https://git.openldap.org/openldap/openldap/-/blob/OPENLDAP_REL_ENG_2_5_14/s… That way the member searches are excluded, but dynlists otherwise work as expected. Here is the dynlist config we're using, just basic support for groupOfURLs/memberURL: overlay dynlist dynlist-attrset groupOfURLs memberURL member I'd like to request a configurable option to exclude dynlists from (member=memberDN) searches. -- You are receiving this mail because: You are on the CC list for the issue.

1 10

[Issue 10083] New: lload: Receiving a NoD while connection is closing already corrupts c_state
by openldap-its＠openldap.org 29 Jan '24

29 Jan '24

https://bugs.openldap.org/show_bug.cgi?id=10083 Issue ID: 10083 Summary: lload: Receiving a NoD while connection is closing already corrupts c_state Product: OpenLDAP Version: unspecified Hardware: All OS: All Status: UNCONFIRMED Keywords: needs_review Severity: normal Priority: --- Component: lloadd Assignee: bugs(a)openldap.org Reporter: ondra(a)mistotebe.net Target Milestone: --- If the backend closes a connection with a NoD, two things happen: we won't be able to write to the socket and we receive the NoD message. lloadd might encounter those in either order, but handle_unsolicited() doesn't expect to be the second one to come in and happily overrides c_state, even if c_unlink() has been called by the write side already. upstream_destroy() eventually discovers the inconsistent state (LLOAD_C_CLOSING vs. LLOAD_C_DYING) and assert()s. A fix to handle_unsolicited() is coming. -- You are receiving this mail because: You are on the CC list for the issue.

1 5

[Issue 10091] New: slapd segfaults when the dynlist overlay is applied on the frontend db (with `<memberOf-ad>@<static-oc>` parameters)
by openldap-its＠openldap.org 29 Jan '24

29 Jan '24

https://bugs.openldap.org/show_bug.cgi?id=10091 Issue ID: 10091 Summary: slapd segfaults when the dynlist overlay is applied on the frontend db (with `<memberOf-ad>@<static-oc>` parameters) Product: OpenLDAP Version: 2.6.6 Hardware: x86_64 OS: Linux Status: UNCONFIRMED Keywords: needs_review Severity: normal Priority: --- Component: overlays Assignee: bugs(a)openldap.org Reporter: philip.schildkamp(a)uni-koeln.de Target Milestone: --- Created attachment 974 --> https://bugs.openldap.org/attachment.cgi?id=974&action=edit Full stacktrace of the segfault Dear OpenLDAP Development-Team, first of all, thank You for Your continued efforts to provide this great software! I've run into a segfault when trying to apply the dynlist overlay to the frontend db. As I'm running Alpine Linux (based on musl libc), I've verified that this segfault also occurs under GLIBC-based distros. Furthermore, I've trimmed my config down to the bare minimum to provide a replicable setting. This segfault only occurs when I'm trying to use the full `dynlist-attrset` configuration (including the `+<memberOf-ad>@<static-oc>` parameters). If I only supply the `<group-oc> <URL-ad> <member-ad>` parts of the configruation, the segfault does not occur. And the segfault does not happen on startup, but when connecting to the running `slapd` instance. The version I'm running: > @(#) $OpenLDAP: slapd 2.6.6 (Aug 7 2023 12:57:03) $ My `slapd.conf` (the same segfault occures through a `cn=config` setup): > moduleload dynlist > > include /etc/openldap/schema/core.schema > > overlay dynlist > dynlist-attrset labeledURIObject labeledURI member+memberOf@groupOfNames > > database ldif > directory /tmp > suffix "dc=example,dc=com" I've attached a complete stacktrace of the segfault, which is traced back to `dynlist.c:2057`. If I can provide any other means of debugging (e.g. a coredump) or help in locating the root of this issue, I'd be happy to! If this issue is known or the dynlist overlay does not support this functionality on the frontend db, I'm sorry for the noise; but as far as I've been able to verify, there is no mention of such a limitation within the `slapo-dynlist` manpage (which does mention the possibility to apply the dynlist overlay to the frontend db), nor did I find an issue regarding exactly this error. Again, thank You for Your efforts and kind regards, Philip Schildkamp -- You are receiving this mail because: You are on the CC list for the issue.

1 8

[Issue 10070] New: Allow running when /etc/resolv.conf is missing
by openldap-its＠openldap.org 29 Jan '24

29 Jan '24

https://bugs.openldap.org/show_bug.cgi?id=10070 Issue ID: 10070 Summary: Allow running when /etc/resolv.conf is missing Product: OpenLDAP Version: unspecified Hardware: All OS: All Status: UNCONFIRMED Keywords: needs_review Severity: normal Priority: --- Component: lloadd Assignee: bugs(a)openldap.org Reporter: ondra(a)mistotebe.net Target Milestone: --- A resolv.conf file might be missing, usually that means that no name services are available (often in test environments) or in some container environments where the resolver is assumed to run on localhost. We should adopt the proposal discussed in https://github.com/libevent/libevent/issues/1155#issuecomment-918826471 which lets us honour the file if it exists but keep the libevent default, allowing to deal with both cases, no name resolution is needed (all URIs are numeric) and the implicit local resolver. -- You are receiving this mail because: You are on the CC list for the issue.

1 5

[Issue 10089] New: regex that does not pass `regtest()` causes the entire process to exit
by openldap-its＠openldap.org 29 Jan '24

29 Jan '24

https://bugs.openldap.org/show_bug.cgi?id=10089 Issue ID: 10089 Summary: regex that does not pass `regtest()` causes the entire process to exit Product: OpenLDAP Version: 2.6.6 Hardware: All OS: All Status: UNCONFIRMED Keywords: needs_review Severity: normal Priority: --- Component: slapd Assignee: bugs(a)openldap.org Reporter: gburd(a)symas.com Target Milestone: --- There are 6 locations in `aclparse.c` in the function `parse_acl()` that call `regtest()` validating a regex expression before its use. Currently, when `regtest()` finds an issue it calls `exit()` and the process must be restarted. It seems that a better approach would be to allow the failures to be processed by the caller where the severity might be better understood. In some (most?) cases it's likely just fine for the process to continue after some information about the issue is logged and resources are released properly. https://git.openldap.org/openldap/openldap/-/blob/master/servers/slapd/aclp… -- You are receiving this mail because: You are on the CC list for the issue.

1 11

[Issue 10105] New: slapd logging fails to add newline with large search filters
by openldap-its＠openldap.org 29 Jan '24

29 Jan '24

https://bugs.openldap.org/show_bug.cgi?id=10105 Issue ID: 10105 Summary: slapd logging fails to add newline with large search filters Product: OpenLDAP Version: 2.6.6 Hardware: All OS: All Status: UNCONFIRMED Keywords: needs_review Severity: normal Priority: --- Component: slapd Assignee: bugs(a)openldap.org Reporter: quanah(a)openldap.org Target Milestone: --- When using slapd logging rather than syslog, it fails to write a newline if the search filter is extremely long. Found this when examining the logs where the search filter has 500 users in it, in the form of: "(&(objectClass=userobject)(|(uid=abc)(uid=xyz)....)" In the slapd log, the filter gets truncated and the next log line is appended, so we end up with ...(uid=joe.hSep 27 18:21:09 hostname slapd[6373]: conn=1234 op=123 SEARCH RESULT tag=101 err=0 qtime=0.xxxx etime=0.xxx nentries=500 text= -- You are receiving this mail because: You are on the CC list for the issue.

1 9

[Issue 10145] New: ldap_url_parse_ext buffer overread
by openldap-its＠openldap.org 29 Jan '24

29 Jan '24

https://bugs.openldap.org/show_bug.cgi?id=10145 Issue ID: 10145 Summary: ldap_url_parse_ext buffer overread Product: OpenLDAP Version: 2.6.6 Hardware: All OS: All Status: UNCONFIRMED Keywords: needs_review Severity: normal Priority: --- Component: libraries Assignee: bugs(a)openldap.org Reporter: joshua(a)joshua.hu Target Milestone: --- Hi there, There is an easy-to-trigger buffer overread in the function ldap_url_parse_ext in libraries/libldap/url.c: 850 url_tmp = skip_url_prefix( url_in, &enclosed, &scheme ); 851 852 if ( url_tmp == NULL ) { 853 return LDAP_URL_ERR_BADSCHEME; 854 } 855 856 assert( scheme != NULL ); 857 858 proto = ldap_pvt_url_scheme2proto( scheme ); 859 if ( proto == -1 ) { 860 return LDAP_URL_ERR_BADSCHEME; 861 } 862 863 /* make working copy of the remainder of the URL */ 864 url = LDAP_STRDUP( url_tmp ); 865 if ( url == NULL ) { 866 return LDAP_URL_ERR_MEM; 867 } 868 869 if ( enclosed ) { 870 p = &url[strlen(url)-1]; 871 872 if( *p != '>' ) { 873 LDAP_FREE( url ); 874 return LDAP_URL_ERR_BADENCLOSURE; 875 } 876 877 *p = '\0'; 878 } The function skip_url_prefix, presented with a url_in that is exactly '<ldap://', will work towards line 870, which will set: p = &url[strlen(0)-1]; This causes a one-byte buffer overread. This issue can be triggered by calling ldap_url_parse_ext with a url of exactly "<ldap://". This issue can be triggered both through the library, and slapd. ================================================================= ==1986888==ERROR: AddressSanitizer: heap-buffer-overflow on address 0x602000004c2f at pc 0x7ffff7eed3c2 bp 0x7fffffffde10 sp 0x7fffffffde08 READ of size 1 at 0x602000004c2f thread T0 #0 0x7ffff7eed3c1 in ldap_url_parse_ext /home/jrogers/openldap-clean/libraries/libldap/url.c:872:7 -- You are receiving this mail because: You are on the CC list for the issue.

1 5

← Newer
1
2
3
4
5
6
7
8
9
Older →

2024

2023

2022

2021

2020

2019

2018

2017

2016

2015

2014

2013

2012

2011

2010

2009

2008

2007

2006

openldap-bugs December 2023