Off by one in _sasl_add_string function

[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

[hyc]

Fyi, was originally reported to us and diagnosed here http://www.openldap.org/its/index.cgi/Incoming?id=9123

[Neustradamus]

If we can have a new release with a solution for this problem...
Thanks to @quanah who gives me the information about this ticket :)

[carnil]

CVE-2019-19906 was assigned for this issue.

[bmanahilov]

CVE-2019-19906 was assigned for this issue.

I see the @GuidoKiener 's fix that was merged is on code that already existed in 2.1.25.
Do you know why this CVE-2019-19906 is referencing 2.1.27 only.
Didn't the same issue already exist in 2.1.25?
Thanks.

[flyn-org]

Will we see a release soon with this fix? CVE-2019-19906 has a base score of high. We are in the process of addressing this in OpenWrt with a local patch:

openwrt/packages#17114
openwrt/packages#17113
openwrt/packages#17112

[quanah]

There's one remaining security issue open that needs addressing before a new release.