https://bugs.openldap.org/show_bug.cgi?id=10147
Issue ID: 10147 Summary: Bind dn is getting malformed inside ldap_sasl_bind function Product: OpenLDAP Version: 2.6.3 Hardware: x86_64 OS: Linux Status: UNCONFIRMED Keywords: needs_review Severity: normal Priority: --- Component: slapd Assignee: bugs@openldap.org Reporter: satishkumar1728@gmail.com Target Milestone: ---
Hi team,
We are using open ldap version 2.6 in one of our application processes. We are using ldap_sasl_bind function defined in open ldap api to send bind request to ldap server. We are passing the dn name to the above function and it is parsing the dn name as expected. We have added some print statements inside ldap_sasl_bind function and it is printing the dn string that we passed to the function. Also, ldap_sasl_bind function will accept const char pointer to dn as an argument. So, it cannot modify the dn string inside the function. But somehow the bind dn is getting malformed and we are getting failed bind response from the ldap server (invalid DN). We did some analysis using tcpdump and we found out that the dn string that we passed to the ldap_sasl_bind function and the dn string from the tcpdump are different. We did some code walkthrough of ldap_sasl_bind function and it is observed that it is doing some ber encoding of dn name inside the function. We are suspecting that the encoding is not happening properly. Example dn that we passed to ldap_sasl_bin function: "uid=abc, ou=users, dc=fds, dc=mr" Dn name that was captured in tcpdump at source: "uid=abc, o dc= dc= dc= dc= dc=mr"
Is there any specific reason for the bind DN to get malformed like this inside ldap_sasl_bind function. Do you have any observations like this in any scenario. Kindly provide some inputs to resolve this issue.
https://bugs.openldap.org/show_bug.cgi?id=10147
--- Comment #1 from Howard Chu hyc@openldap.org --- Nothing like you describe has ever been reported before. ldap_sasl_bind() doesn't parse the DN at all, it is passed as-is to the underlying socket.
I suggest you single-step with a debugger through the code to see where things are going wrong. Turning on the debug flags in libldap may help reveal some information as well.
https://bugs.openldap.org/show_bug.cgi?id=10147
Quanah Gibson-Mount quanah@openldap.org changed:
What |Removed |Added ---------------------------------------------------------------------------- Keywords|needs_review | Status|UNCONFIRMED |RESOLVED Resolution|--- |FEEDBACK
https://bugs.openldap.org/show_bug.cgi?id=10147
Quanah Gibson-Mount quanah@openldap.org changed:
What |Removed |Added ---------------------------------------------------------------------------- Status|RESOLVED |VERIFIED
https://bugs.openldap.org/show_bug.cgi?id=10147
satishkumar1728@gmail.com changed:
What |Removed |Added ---------------------------------------------------------------------------- Status|VERIFIED |UNCONFIRMED Resolution|FEEDBACK |---
--- Comment #2 from satishkumar1728@gmail.com --- Hi,
Apologies for the delayed response. To replicate the scenario, We deployed this openldap libraries on two different servers and performed the testing. Issue was reproduced in one application deployed on a physical server, whereas it is not reproduced in application deployed on another virtual machine. After debugging the code, we found out that the bind dn is getting corrupted in the following code.
unsigned char *p = ber_prepend_len( lenptr + SOS_LENLEN, len ); ber_len_t unused = p - lenptr; if ( unused != 0 ) { /* length(length) < the reserved SOS_LENLEN bytes */ xlen -= unused; AC_MEMCPY( lenptr, p, xlen ); ber->ber_sos_ptr = (char *) lenptr + xlen; }
This code is present inside the ber_put_seqorset function which is a part of encode.c file. This ber_put_seqorset function is getting called from ber_printf function which will insert bind dn string into ber element.
In the above code, bind dn is getting malformed in AC_MEMCPY macro call. BEFORE AC_MEMCPY macro call: lenptr + SOS_LENLEN = ^B^A^C^D uid=abc, ou=users, dc=fds, dc=mr~@^Fpasskey AFTER AC_MEMCPY macro call: lenptr + SOS_LENLEN = uid=abc,users, ds, dc= dc= dc=mr~@^Fpasskeyskey
As per the doucmentation, AC_MEMCPY will do the safe copy of memory blocks. By default it is calling the memcpy function inside AC_MEMCPY macro(depends on the compile time flags HAVE_MEMMOVE,HAVE_BCOPY). We replaced AC_MEMCPY with memmove and the issue was resolved and the bind dn is parsed as expected.
memmove will check for overlapping memory locations, whereas memcpy doesn't.
So, Can we replace this AC_MEMCPY with memmove? Or, Can we enable the HAVE_MEMMOVE during compilation? If yes, can you please provide some inputs on the impact of this code change. Is there any other specific reason behind this abrupt behavior in one server. If yes, Kindly let us know so that we will address that one instead of making the code change in the above function.
Thanks, Satish S
https://bugs.openldap.org/show_bug.cgi?id=10147
--- Comment #3 from Ondřej Kuzník ondra@mistotebe.net --- On Tue, Jan 30, 2024 at 10:40:39AM +0000, openldap-its@openldap.org wrote:
As per the doucmentation, AC_MEMCPY will do the safe copy of memory blocks. By default it is calling the memcpy function inside AC_MEMCPY macro(depends on the compile time flags HAVE_MEMMOVE,HAVE_BCOPY). We replaced AC_MEMCPY with memmove and the issue was resolved and the bind dn is parsed as expected.
memmove will check for overlapping memory locations, whereas memcpy doesn't.
So, Can we replace this AC_MEMCPY with memmove? Or, Can we enable the HAVE_MEMMOVE during compilation? If yes, can you please provide some inputs on the impact of this code change. Is there any other specific reason behind this abrupt behavior in one server. If yes, Kindly let us know so that we will address that one instead of making the code change in the above function.
Hi Satish, seems that ./configure cannot find a usable memmove/bcopy in your build environment, that's what you want to look into next.
Regards,
-
openldap-its＠openldap.org