heap buffer overflow read in coap_send function about libcoap

[mrdeep1]

@zambbo Thank you for raising this. I believe that (adding in if (coap_pdu_resize(pdu, pdu->used_size + 1)) { wrapper)

diff --git a/src/net.c b/src/net.c
index e62eaa67..ac429bc9 100644
--- a/src/net.c
+++ b/src/net.c
@@ -1287,17 +1287,19 @@ coap_send_internal(coap_session_t *session, coap_pdu_t *pdu) {
       /* Need to check that we are not seeing this proxy in the return loop */
       if (pdu->data && opt == NULL) {
         if (pdu->used_size + 1 <= pdu->max_size) {
-          char *a_match;
-          size_t data_len = pdu->used_size - (pdu->data - pdu->token);
-          pdu->data[data_len] = '\000';
-          a_match = strstr((char*)pdu->data, cp);
-          if (a_match && (a_match == (char*)pdu->data || a_match[-1] == ' ') &&
-              ((size_t)(a_match - (char*)pdu->data + len) == data_len ||
-               a_match[len] == ' ')) {
-            coap_log_warn("Proxy loop detected '%s'\n",
-                     (char*)pdu->data);
-            coap_delete_pdu(pdu);
-            return (coap_mid_t)COAP_DROPPED_RESPONSE;
+          if (coap_pdu_resize(pdu, pdu->used_size + 1)) {
+            char *a_match;
+            size_t data_len = pdu->used_size - (pdu->data - pdu->token);
+            pdu->data[data_len] = '\000';
+            a_match = strstr((char*)pdu->data, cp);
+            if (a_match && (a_match == (char*)pdu->data || a_match[-1] == ' ') &&
+                ((size_t)(a_match - (char*)pdu->data + len) == data_len ||
+                 a_match[len] == ' ')) {
+              coap_log_warn("Proxy loop detected '%s'\n",
+                       (char*)pdu->data);
+              coap_delete_pdu(pdu);
+              return (coap_mid_t)COAP_DROPPED_RESPONSE;
+            }
           }
         }
       }

should fix your issue. Please confirm

[zambbo]

After modifying the code, there are no errors occurring.

[mrdeep1]

Fixed (in slightly re-worked code) in #1065.

[tijuca]

Is there a respective release for 4.3.1+ planned which does include this fix?
This issue has got the CVE number CVE-2023-3062 assigned and typically fixed versions will get prepared by the upstream projects to handle such issues. Note that only the CVE fix is targeted by such releases!

I've tried to cherry pick the underlying commit on top of tag v4.3.1 but this is failing as the code has changed afterwards in src/net.c. I'll need help from the upstream project to prepare fixed version for Debian.

BTW: The GitHub project of libcoap could benefit if there would be some information available in case security issues need to get reported. There is no further information available on https://github.com/obgm/libcoap/security

[mrdeep1]

@tijuca Thanks for raising this - I was not aware of this CVE. The code that fixes this for 4.3.1 is

iff --git a/src/net.c b/src/net.c
index 9885944..e259ab0 100644
--- a/src/net.c
+++ b/src/net.c
@@ -1305,19 +1305,27 @@ coap_send_internal(coap_session_t *session, coap_pdu_t *pdu)
 
       /* Need to check that we are not seeing this proxy in the return loop */
       if (pdu->data && opt == NULL) {
-        if (pdu->used_size + 1 <= pdu->max_size) {
-          char *a_match;
-          size_t data_len = pdu->used_size - (pdu->data - pdu->token);
-          pdu->data[data_len] = '\000';
-          a_match = strstr((char*)pdu->data, cp);
-          if (a_match && (a_match == (char*)pdu->data || a_match[-1] == ' ') &&
-              ((size_t)(a_match - (char*)pdu->data + len) == data_len ||
-               a_match[len] == ' ')) {
-            coap_log(LOG_WARNING, "Proxy loop detected '%s'\n",
-                     (char*)pdu->data);
-            coap_delete_pdu(pdu);
-            return (coap_mid_t)COAP_DROPPED_RESPONSE;
-          }
+        char *a_match;
+        size_t data_len;
+
+        if (pdu->used_size + 1 > pdu->max_size) {
+          /* No space */
+          return (coap_mid_t)COAP_DROPPED_RESPONSE;
+        }
+        if (!coap_pdu_resize(pdu, pdu->used_size + 1)) {
+          /* Internal error */
+          return (coap_mid_t)COAP_DROPPED_RESPONSE;
+        }
+        data_len = pdu->used_size - (pdu->data - pdu->token);
+        pdu->data[data_len] = '\000';
+        a_match = strstr((char*)pdu->data, cp);
+        if (a_match && (a_match == (char*)pdu->data || a_match[-1] == ' ') &&
+            ((size_t)(a_match - (char*)pdu->data + len) == data_len ||
+             a_match[len] == ' ')) {
+          coap_log(LOG_WARNING, "Proxy loop detected '%s'\n",
+                   (char*)pdu->data);
+          coap_delete_pdu(pdu);
+          return (coap_mid_t)COAP_DROPPED_RESPONSE;
         }
       }
       if (pdu->used_size + len + 1 <= pdu->max_size) {

I see also that CVE-2023-35862 has been published (which I did know was likely to happen) but this is for code post 4.3.1.

It is currently planned to release 4.3.2 when #611 is signed off and merged. However, what is the best way to name an interim release that contains CVE-2023-30362 if I was to do that to help you?

[tijuca]

Thanks for the diff, that's what I was needing. I've prepared a new Debian version 4.3.1-2 which is including the fix for CVE-2023-30362.

Newer usptream versions are targeted for unstable/sid and migrate then to testing. The version in the stable releases of Debian do not change normally. CVE fixes or regressions get fixed by only fixing the underlying problem. Newer versions for the stable release can be provided by the backports archive (which I've done regularly in the past).

The other CVE issue I need to compare with the security team. But I suspect this this get need to be fixed the same as this one here.

[mrdeep1]

The other CVE issue I need to compare with the security team. But I suspect this this get need to be fixed the
same as this one here.

The code in question (OSCORE support) is not in the 4.3.1 release, only in the develop branch.

[tijuca]

Then this doesn't affects the current version in Debian stable. Thanks for clear out.

[fpic78]

Hi.
I have a version libcoap 4.2.1.
Is this version affected by this CVE?
Function coap_send_internal is not present here. Can you provide a patch if this version is affected?
Thanks

[mrdeep1]

4.2.1 is not affected. This issue was introduced when support for RFC8768 was added (4.3.0).

[fpic78]

Ok. Thanks for you confirmation on my suspects.