Libcurl at commit 04739054cdac5a0614fb94e3655e313c03399f35 contains an invalid invocation of free() in the function utf8asn1str() at lib/vtls/x509asn1.c:397.

The relevant code can be seen below:

static CURLcode
utf8asn1str(struct dynbuf *to, int type, const char *from, const char *end)
{
    // --- snip ---
    
    if(type == CURL_ASN1_UTF8_STRING) {
        // --- snip ---
    }
    else {
        while(!result && (from < end)) {
            char buf[4]; /* decode buffer */
            
            // --- snip ---
        
            if(wc >= 0x00200000) {
                free(buf);
                /* Invalid char. size for target encoding. */
                return CURLE_WEIRD_SERVER_REPLY;
            }
        }
    }
}

buf is located on the stack and not the heap, which means that buf will be falsely treated as a heap chunk.
This poses a security risk because the address of buf can be returned in subsequent calls to malloc(), which causes
the stack contents at that point to be overwritten.
The stack holds data that determines the control flow of the application. This can either be local variables that indirectly
determine the control flow of their corresponding functions or security-critical metadata liked saved framepointers or return addresses.
If an attacker manages to overwrite these kinds of stack contents he/she can gain control over the control flow of the application.

Exploit Scenario

Consider the following scenario that demonstrates how to leverage the invalid free() to overwrite return addresses:

1. The attacker sets up a malicious server with a TLS certificate that triggers the invalid free()
2. An application using libcurl connects to the server and during the connect() phase parses the invalid certificate.
   This causes the stack address to be put into the freelist of the allocator.
3. The attacker interacts with the client in a way that causes the stack address to be returned by a malloc() call
   and used to store data from the attacker
4. Depending on the state of the stack, the attacker can now overwrite local variables, pointers or security-critical metadata.
   The worst case would be that a return address gets overwritten with a ROP-chain in order to
   gain control over the execution of the program

One environment where that scenario could work out is Ubuntu bionic, where the glibc does not check whether the argument to free() actually refers to a valid heap chunk.

Patch

The fix for this vulnerability is pretty straight forward, just remove the call to free():

diff --git a/lib/vtls/x509asn1.c b/lib/vtls/x509asn1.c
index cea88e668..ddfb65344 100644
--- a/lib/vtls/x509asn1.c
+++ b/lib/vtls/x509asn1.c
@@ -394,7 +394,6 @@ utf8asn1str(struct dynbuf *to, int type, const char *from, const char *end)
         if(wc >= 0x00000800) {
           if(wc >= 0x00010000) {
             if(wc >= 0x00200000) {
-              free(buf);
               /* Invalid char. size for target encoding. */
               return CURLE_WEIRD_SERVER_REPLY;
             }

Impact

I assess the impact of this vulnerability to be “High” because

1. The invalid free() is easy to trigger since it happens during the TLS handshake
2. An overwrite of memory contents with attacker-controlled data poses a great security risk