https://bugs.openldap.org/show_bug.cgi?id=10162
Issue ID: 10162
Summary: Fix for binary attributes data corruption in back-sql
Product: OpenLDAP
Version: unspecified
Hardware: All
OS: All
Status: UNCONFIRMED
Keywords: needs_review
Severity: normal
Priority: ---
Component: backends
Assignee: bugs(a)openldap.org
Reporter: dex.tracers(a)gmail.com
Target Milestone: ---
Created attachment 1006
--> https://bugs.openldap.org/attachment.cgi?id=1006&action=edit
Fix for binary attributes corruption on backed-sql
I've configured slapd to use back-sql (mariadb through odbc) and observed
issues with the BINARY data retrievals from the database. The length of the
attributes was properly reported, but the correct data inside was always 16384
bytes and after that point - some junk (usually filled-up with AAAAAAAA and
some other attributes data from memory).
During the debugging - I've noticed that:
- The MAX_ATTR_LEN (16384 bytes) is used to set the length of the data for
BINARY columns when SQLBindCol is done inside of the
"backsql_BindRowAsStrings_x" function
- After SQLFetch is done - data in row->cols[i] is fetched up to the specified
MAX_ATTR_LEN
- After SQLFetch is done - the correct data size (greater than MAX_ATTR_LEN) is
represented inside of the row->value_len
I'm assuming that slapd allocates the pointer in memory (row->cols[i]), fills
it with the specified amount of data (MAX_ATTR_LEN), but when forming the
actual attribute data - uses the length from row->value_len and so everything
from 16384 bytes position till row->value_len is just a junk from the memory
(uninitialized, leftovers, data from other variables).
After an investigation, I've find-out that:
- for BINARY or variable length fields - SQLGetData should be used
- SQLGetData supports chunked mode (if length is unknown) or full-read mode if
the length is known
- it could be used in pair with SQLBindCol after SQLFetch (!)
Since we have the correct data length inside of row->value_len, I've just added
the code to the backsql_get_attr_vals() function to overwrite the corrupted
data with the correct data by issuing SQLGetData request. And it worked -
binary data was properly retrieved and reported over LDAP!
My current concerns / help needed - I'm not very familiar with the memory
allocation/deallocation mechanisms, so I'm afraid that mentioned change can
lead to memory corruption (so far not observed).
Please review attached patch (testing was done on OPENLDAP_REL_ENG_2_5_13, and
applied on the master branch for easier review/application).
--
You are receiving this mail because:
You are on the CC list for the issue.
https://bugs.openldap.org/show_bug.cgi?id=9796
Issue ID: 9796
Summary: Deprecate GnuTLS support
Product: OpenLDAP
Version: 2.6.1
Hardware: All
OS: All
Status: UNCONFIRMED
Keywords: needs_review
Severity: normal
Priority: ---
Component: libraries
Assignee: bugs(a)openldap.org
Reporter: quanah(a)openldap.org
Target Milestone: ---
Support for GnuTLS was added specifically for the Debian (and thus Ubuntu) due
to the license objections at the time that the Debian project had for the
OpenSSL license.
Since that time, Debian has reclassified OpenSSL as a core library and the
OpenSSL project has resolved the original complaint by licensing OpenSSL 3 and
later under the Apache License v2.
Thus there is no longer a reason to maintain support for GnuTLS and given the
long standing concerns over the security and quality of the GnuTLS bridge in
addition to the extra cost of maintaining that code, it should be marked as
deprecated and removed in a future release.
--
You are receiving this mail because:
You are on the CC list for the issue.
https://bugs.openldap.org/show_bug.cgi?id=10490
Issue ID: 10490
Summary: Bump library minor version(s)
Product: OpenLDAP
Version: unspecified
Hardware: All
OS: All
Status: UNCONFIRMED
Keywords: needs_review
Severity: normal
Priority: ---
Component: libraries
Assignee: bugs(a)openldap.org
Reporter: ondra(a)mistotebe.net
Target Milestone: ---
Tracking bug for 2.7 branchpoint if we expose new interfaces in either library.
--
You are receiving this mail because:
You are on the CC list for the issue.
https://bugs.openldap.org/show_bug.cgi?id=10488
Issue ID: 10488
Summary: Multiple out-of-bounds reads in servers/slapd/result.c
v2ref() function
Product: OpenLDAP
Version: unspecified
Hardware: All
OS: All
Status: UNCONFIRMED
Keywords: needs_review
Severity: normal
Priority: ---
Component: slapd
Assignee: bugs(a)openldap.org
Reporter: wangxiaomeng(a)kylinos.cn
Target Milestone: ---
Created attachment 1142
--> https://bugs.openldap.org/attachment.cgi?id=1142&action=edit
Fix two out-of-bounds reads in servers/slapd/result.c v2ref() function
The v2ref() function in servers/slapd/result.c is responsible for converting
LDAPv3 referrals to an LDAPv2-compatible string format. Two separate
out-of-bounds read vulnerabilities exist in this function, both caused by
insufficient checks for zero-length data before accessing the last character of
the data buffer.
Vulnerability 1: Out-of-bounds read in text buffer handling
Location: servers/slapd/result.c, line 94 (within the v2ref() function):
Vulnerable Code:
if ( text != NULL ) {
len = strlen( text );
if (text[len-1] != '\n') {
i = 1;
}
}
When the 'text' parameter is non-NULL but points to an empty string (""),
strlen(text) returns 0. Accessing text[len-1] (i.e., text[-1]) results in an
out-of-bounds read of one byte before the start of the 'text' buffer.
Vulnerability 2: Out-of-bounds read in BerValue referral handling
Location: servers/slapd/result.c, line 115 (within the v2ref() function)
Vulnerable Code:
len += ref[i].bv_len;
if (ref[i].bv_val[ref[i].bv_len-1] != '/') {
++len;
}
When ref[i].bv_val is non-NULL but ref[i].bv_len is 0 (a valid state per LDAP
BerValue semantics, representing an empty string), accessing
ref[i].bv_val[ref[i].bv_len-1] (i.e., ref[i].bv_val[-1]) results in an
out-of-bounds read of one byte before the start of the ref[i].bv_val buffer.
Fix
Add checks for zero-length data before accessing the last character of the
respective buffers. The fix addresses both vulnerabilities with minimal,
targeted changes that preserve the original functionality.
--
You are receiving this mail because:
You are on the CC list for the issue.
https://bugs.openldap.org/show_bug.cgi?id=10480
Issue ID: 10480
Summary: Use after free in cn=config replication
Product: OpenLDAP
Version: unspecified
Hardware: All
OS: All
Status: UNCONFIRMED
Keywords: needs_review
Severity: normal
Priority: ---
Component: backends
Assignee: bugs(a)openldap.org
Reporter: ondra(a)mistotebe.net
Target Milestone: ---
If a renumber needs to happen, cn=config frees e->e_name, but some code (e.g.
syncrepl) sets op->o_req_dn to point to the same and as such it can't be used
anymore. This causes a crash in syncrepl (if LDAP_DEBUG_SYNC is on) and
accesslog during cn=config replication.
Either syncrepl (and others) shouldn't do this or cn=config should check for
this case and adjust o_req_dn after the fact.
--
You are receiving this mail because:
You are on the CC list for the issue.
https://bugs.openldap.org/show_bug.cgi?id=10499
Issue ID: 10499
Summary: Enable test-level tracking in CI
Product: OpenLDAP
Version: unspecified
Hardware: All
OS: All
Status: UNCONFIRMED
Keywords: needs_review
Severity: normal
Priority: ---
Component: test suite
Assignee: bugs(a)openldap.org
Reporter: ondra(a)mistotebe.net
Target Milestone: ---
Gitlab supports parsing junit-style XML reports. We can emit something like
this from our test suite and get a better idea how our tests perform/which test
failed at a glance.
--
You are receiving this mail because:
You are on the CC list for the issue.
https://bugs.openldap.org/show_bug.cgi?id=9367
Issue ID: 9367
Summary: back-mdb: encryption support
Product: OpenLDAP
Version: unspecified
Hardware: All
OS: All
Status: UNCONFIRMED
Severity: normal
Priority: ---
Component: backends
Assignee: bugs(a)openldap.org
Reporter: quanah(a)openldap.org
Target Milestone: ---
Need to add encryption support to the back-mdb backend, depends on issue#9364
--
You are receiving this mail because:
You are on the CC list for the issue.
https://bugs.openldap.org/show_bug.cgi?id=9225
Bug ID: 9225
Summary: back-mdb: Add support for PREPARE/2-phase commit
Product: OpenLDAP
Version: 2.4.50
Hardware: All
OS: All
Status: UNCONFIRMED
Severity: normal
Priority: ---
Component: backends
Assignee: bugs(a)openldap.org
Reporter: quanah(a)openldap.org
Target Milestone: ---
Add support for PREPARE/2-phase commit in back-mdb
--
You are receiving this mail because:
You are on the CC list for the bug.
https://bugs.openldap.org/show_bug.cgi?id=10274
Issue ID: 10274
Summary: Replication issue on MMR configuration
Product: OpenLDAP
Version: 2.5.14
Hardware: All
OS: Linux
Status: UNCONFIRMED
Keywords: needs_review
Severity: normal
Priority: ---
Component: slapd
Assignee: bugs(a)openldap.org
Reporter: falgon.comp(a)gmail.com
Target Milestone: ---
Created attachment 1036
--> https://bugs.openldap.org/attachment.cgi?id=1036&action=edit
In this attachment you will find 2 openldap configurations for 2 instances +
slamd conf exemple + 5 screenshots to show the issue and one text file to
explain what you see
Hello we are openning this issue further to the initial post in technical :
https://lists.openldap.org/hyperkitty/list/openldap-technical@openldap.org/…
Issue :
We are working on a project and we've come across an issue with the replication
after performance testing :
*Configuration :*
RHEL 8.6
OpenLDAP 2.5.14
*MMR-delta *configuration on multiple servers attached
300,000 users configured and used for tests
*olcLastBind: TRUE*
Use of SLAMD (performance shooting)
*Problem description:*
We are currently running performance and resilience tests on our infrastructure
using the SLAMD tool configured to perform BINDs and MODs on a defined range of
accounts.
We use a load balancer (VIP) to poll all of our servers equally. (but it is
possible to do performance tests directly on each of the directories)
With our current infrastructure we're able to perform approximately 300
MOD/BIND/s. Beyond that, we start to generate delays and can randomly come
across one issue.
However, when we run performance tests that exceed our write capacity, our
replication between servers can randomly create an incident with directories
being unable to catch up with their replication delay.
The directories update their contextCSNs, but extremely slowly (like freezing).
From then on, it's impossible for the directories to catch again. (even with no
incoming traffic)
A restart of the instance is required to perform a full refresh and solve the
incident.
We have enabled synchronization logs and have no error or refresh logs to
indicate a problem ( we can provide you with logs if necessary).
We suspect a write collision or a replication conflict but this is never write
in our sync logs.
We've run a lot of tests.
For example, when we run a performance test on a single live server, we don't
reproduce the problem.
Anothers examples: if we define different accounts ranges for each server with
SALMD, we don't reproduce the problem either.
If we use only one account for the range, we don't reproduce the problem
either.
______________________________________________________________________
I have add some screenshots on attachement to show you the issue and all the
explanations.
______________________________________________________________________
*Symptoms :*
One or more directories can no longer be replicated normally after performance
testing ends.
No apparent error logs.
Need a restart of instances to solve the problem.
*How to reproduce the problem:*
Have at least two servers in MMR mode
Set LastBind to TRUE
Perform a SLAMD shot from a LoadBalancer in bandwidth mode OR start multiple
SLAMD test on same time for each server with the same account range.
Exceed the maximum write capacity of the servers.
*SLAMD configuration :*
authrate.sh --hostname ${HOSTNAME} --port ${PORTSSL} \
--useSSL --trustStorePath ${CACERTJKS} \
--trustStorePassword ${CACERTJKSPW} --bindDN "${BINDDN}" \
--bindPassword ${BINDPW} --baseDN "${BASEDN}" \
--filter "(uid=[${RANGE}])" --credentials ${USERPW} \
--warmUpIntervals ${WARMUP} \
--numThreads ${NTHREADS} ${ARGS}
--
You are receiving this mail because:
You are on the CC list for the issue.
https://bugs.openldap.org/show_bug.cgi?id=10495
Issue ID: 10495
Summary: Environment variable for Systemd is ignored by
configure
Product: OpenLDAP
Version: 2.6.13
Hardware: All
OS: Linux
Status: UNCONFIRMED
Keywords: needs_review
Severity: normal
Priority: ---
Component: build
Assignee: bugs(a)openldap.org
Reporter: openldap.aftermost863(a)passinbox.com
Target Milestone: ---
Hello,
When using the configure script to generate the Makefile, the documentation in
the --help option states that the environment variable 'systemdsystemunitdir'
can be used to override the default system path for Systemd units.
However, this does not work: if I export the variable with a valid existing
path (e.g. 'export systemdsystemunitdir=/tmp/test') and then run ./configure,
the variable is found but is ignored in the output variables and is therefore
not used in the Makefile.
config.log:
...
## ---------------- ##
## Cache variables. ##
## ---------------- ##
...
ac_cv_env_systemdsystemunitdir_set=set
ac_cv_env_systemdsystemunitdir_value=/tmp/test
...
## ----------------- ##
## Output variables. ##
## ----------------- ##
...
systemdsystemunitdir='/usr/lib/systemd/system'
...
The configure script seems to override that variable on line 23942:
systemdsystemunitdir=
I don’t quite understand why this line is there, and it seems suspicious to me.
However, if I remove it and run ./configure again in the exact same shell,
config.log now shows the correct path in the output variables, and the Makefile
uses it correctly afterward:
...
## ---------------- ##
## Cache variables. ##
## ---------------- ##
...
ac_cv_env_systemdsystemunitdir_set=set
ac_cv_env_systemdsystemunitdir_value=/tmp/test
...
pkg_cv_systemdsystemunitdir=/tmp/test
## ----------------- ##
## Output variables. ##
## ----------------- ##
...
systemdsystemunitdir='/tmp/test'
I had this issue on both Debian 13 (using bash) and Arch Linux (using zsh).
--
You are receiving this mail because:
You are on the CC list for the issue.