Skip to content

Off by one in _sasl_add_string function #587

Closed
@stze

Description

@stze

Dear Cyrus SASL team —

During tests against openldap 2.4.48, I have detected an off-by-one error in _sasl_add_string function. In case of openldap this bug can cause a denial-of-service condition or has other unspecified impact.

Valgrind output from openldap

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)

Patch

diff --git a/lib/common.c b/lib/common.c
index bc3bf1df..9969d6aa 100644
--- a/lib/common.c
+++ b/lib/common.c
@@ -190,7 +190,7 @@ int _sasl_add_string(char **out, size_t *alloclen,

   if (add==NULL) add = "(null)";

-  addlen=strlen(add); /* only compute once */
+  addlen=strlen(add)+1; /* only compute once */
   if (_buf_alloc(out, alloclen, (*outlen)+addlen)!=SASL_OK)
     return SASL_NOMEM;

Please let me know what additional information I can provide to fix the issue.

-Stephan Zeisberg

Metadata

Metadata

Assignees

No one assigned

    Labels

    No labels
    No labels

    Type

    No type

    Projects

    No projects

    Milestone

    No milestone

    Relationships

    None yet

    Development

    No branches or pull requests

    Issue actions