A denial-of-service vulnerability exists in the WS-Security plugin functionality of Genivia gSOAP 2.8.107. A specially crafted SOAP request can lead to denial of service. An attacker can send an HTTP request to trigger this vulnerability.

**Summary**

A denial-of-service vulnerability exists in the WS-Security plugin functionality of Genivia gSOAP 2.8.107. A specially crafted SOAP request can lead to denial of service. An attacker can send an HTTP request to trigger this vulnerability.

**Tested Versions**

Genivia gSOAP 2.8.107

**Product URLs**

https://www.genivia.com/products.html#gsoap

**CVSSv3 Score**

7.5 - CVSS:3.0/AV:N/AC:L/PR:N/UI:N/S:U/C:N/I:N/A:H

**CWE**

CWE-476 - NULL Pointer Dereference

**Details**

The gSOAP toolkit is a C/C++ library for developing XML-based web services. It includes several plugins to support the implementation of SOAP and web service standards. The framework also provides multiple deployment options including modules for both IIS and Apache, standalone CGI scripts and its own standalone HTTP service.

One of the many plugins provided by gSOAP includes the wsse plugin for supporting the WS-Security specification. The BinarySecurityToken element can be used to provide encoded X509 certficates. The BinarySecurityToken element includes both a EncodingType and a ValueType attribute which can include URIs that defined the data format for this field. Due to an uninitialized pointer being used during the processing of this element, it is possible to trigger a denial of service condition depending on the pre-existing data that the location of this pointer at the time of creation.

The pointer is first created within soap\_wsse\_get\_BinarySecurityTokenX509.

    soap_wsse_get_BinarySecurityTokenX509(struct soap *soap, const char *id)
    {
      X509 *cert = NULL;
      char *valueType = NULL;
    #if (OPENSSL_VERSION_NUMBER >= 0x0090800fL)
      const unsigned char *data;  <------- Not initialized
    #else
      unsigned char *data;  <------- Not initialized
    #endif
      int size;
      DBGFUN1("soap_wsse_get_BinarySecurityTokenX509", "id=%s", id?id:"");
      if (!soap_wsse_get_BinarySecurityToken(soap, id, &valueType, (unsigned char**)&data, &size) <----- data should be initialized during this call
       && valueType
       && !strcmp(valueType, wsse_X509v3URI))
        cert = d2i_X509(NULL, &data, size); <------ Depending on the data that data points to, a number of access violations can occur here.
      /* verify the certificate */
      if (cert && soap_wsse_verify_X509(soap, cert))
      {
        X509_free(cert);
        cert = NULL;
      }
      return cert;
    }
    
    The parser attempts to decode the token based on the EncodingType.  If Encoding type is set but doesn't match one of the two hardcoded URIs, data will also not be set here.
    Finally, because the only check is that data is not null, and since it wasn't initialized as null, this function returns SOAP_OK and processing continues.
    
     soap_wsse_get_BinarySecurityToken(struct soap *soap, const char *id, char **valueType, unsigned char **data, int *size)
    {
      _wsse__BinarySecurityToken *token = soap_wsse_BinarySecurityToken(soap, id);
      DBGFUN1("soap_wsse_get_BinarySecurityToken", "id=%s", id?id:"");
      if (token)
      {
        *valueType = token->ValueType;
        if (!token->EncodingType || !strcmp(token->EncodingType, wsse_Base64BinaryURI)) 
          *data = (unsigned char*)soap_base642s(soap, token->__item, NULL, 0, size);
        else if (!strcmp(token->EncodingType, wsse_HexBinaryURI))
          *data = (unsigned char*)soap_hex2s(soap, token->__item, NULL, 0, size);
        if (*data) <------ Passes as long as the uninitizlied pointer data points to a non-null
          return SOAP_OK;
      }
      return soap_wsse_fault(soap, wsse__SecurityTokenUnavailable, "BinarySecurityToken required");
    }
    

**Crash Information**

    Program received signal SIGSEGV, Segmentation fault.
    (gdb) bt
    #0  0x00007ffff771327b in ASN1_get_object () from /usr/lib/x86_64-linux-gnu/libcrypto.so.1.1
    #1  0x00007ffff771a7a8 in ?? () from /usr/lib/x86_64-linux-gnu/libcrypto.so.1.1
    #2  0x00007ffff771b98e in ?? () from /usr/lib/x86_64-linux-gnu/libcrypto.so.1.1
    #3  0x00007ffff771c67d in ASN1_item_ex_d2i () from /usr/lib/x86_64-linux-gnu/libcrypto.so.1.1
    #4  0x00007ffff771c6fb in ASN1_item_d2i () from /usr/lib/x86_64-linux-gnu/libcrypto.so.1.1
    #5  0x00000000005d0b5e in soap_wsse_get_BinarySecurityTokenX509 (soap=0x7ffff7fbe010, id=<optimized out>) at ../../plugin/wsseapi.c:3161
    #6  0x00000000005d5361 in soap_wsse_get_KeyInfo_SecurityTokenReferenceX509 (soap=0x7ffff7fbe010) at ../../plugin/wsseapi.c:4510
    #7  0x00000000005d430b in soap_wsse_verify_Signature (soap=0x7ffff7fbe010) at ../../plugin/wsseapi.c:3812
    #8  0x00000000005e2234 in soap_wsse_preparefinalrecv (soap=0x7ffff7fbe010) at ../../plugin/wsseapi.c:7659
    #9  0x000000000057de14 in soap_end_recv (soap=0x7ffff7fbe010) at ../../stdsoap2.c:11512
    #10 0x00000000005319a6 in soap_serve___wst__RequestSecurityToken (soap=0x7ffff7fbe010) at soapServer.c:95
    #11 0x0000000000531695 in soap_serve_request (soap=0x7ffff7fbe010) at soapServer.c:62
    #12 0x0000000000531343 in soap_serve (soap=0x7ffff7fbe010) at soapServer.c:37
    #13 0x00000000004065bd in main (argc=2, argv=0x7fffffffe4b8) at wstdemo.c:204
    0x00007ffff771327b in ASN1_get_object () from /usr/lib/x86_64-linux-gnu/libcrypto.so.1.1
    

**Timeline**

2020-11-05 - Vendor Disclosure  
2020-12-16 - Vendor advised patch released on 2020-11-20  
2021-01-05 - Public Release

Discovered by a member of Cisco Talos.

CVE-2020-13578: TALOS-2020-1189 || Cisco Talos Intelligence Group

**Summary**

A denial-of-service vulnerability exists in the WS-Security plugin functionality of Genivia gSOAP 2.8.107. A specially crafted SOAP request can lead to denial of service. An attacker can send an HTTP request to trigger this vulnerability.

**Tested Versions**

Genivia gSOAP 2.8.107

**Product URLs**

https://www.genivia.com/products.html#gsoap

**CVSSv3 Score**

7.5 - CVSS:3.0/AV:N/AC:L/PR:N/UI:N/S:U/C:N/I:N/A:H

**CWE**

CWE-476 - NULL Pointer Dereference

**Details**

The gSOAP toolkit is a C/C++ library for developing XML-based web services. It includes several plugins to support the implementation of SOAP and web service standards. The framework also provides multiple deployment options including modules for both IIS and Apache, standalone CGI scripts and its own standalone HTTP service.

One of the many plugins provided by gSOAP includes the wsse plugin for supporting the WS-Security specification. The KeyInfo element can be used to specifiy certain key and encryption type information. Within the KeyInfo element, a SecurityTokenReference may be used to to reference elements from other parts of the documents. Finally, within this reference element, a KeyIdentifier element may be included. A denial of service condition can occur due to a null pointer dereference if the KeyIdentifier elements does not include a ValueType attribute.

keytype is set here but is never checked to make sure it’s valid.

    5095 att = soap_att_get(elt, NULL, "ValueType");
    5096 keytype = soap_att_get_text(att);
    5097 keydata = soap_elt_get_text(elt);
    

soap\_att\_get\_text only checks att but not att->text

    2662 soap_att_get_text(const struct soap_dom_attribute *att)
    2663 {
    2664   if (att)
    2665     return att->text;
    2666   return NULL;
    2667 }
    

At this point, keytype is never validated before it is used.

    5145       if (!strcmp(keytype, wsse_X509v3URI))
    

**Crash Information**

    (gdb) r ns 8080
    Starting program: /gsoap-2.8-wsa/gsoap/samples/wst/wstdemo ns 8080
    [Thread debugging using libthread_db enabled]
    Using host libthread_db library "/lib/x86_64-linux-gnu/libthread_db.so.1".
    Server started at port 8080
    Accepting connection from IP 127.0.0.1
    
    Program received signal SIGSEGV, Segmentation fault.
    __strcmp_ssse3 () at ../sysdeps/x86_64/multiarch/../strcmp.S:173
    173	../sysdeps/x86_64/multiarch/../strcmp.S: No such file or directory.
    (gdb) bt
    #0  __strcmp_ssse3 () at ../sysdeps/x86_64/multiarch/../strcmp.S:173
    #1  0x00005555555f8ab5 in soap_wsse_verify_EncryptedKey (soap=0x7ffff7fbe010) at ../../plugin/wsseapi.c:5145
    #2  0x00005555555fcbf0 in soap_wsse_element_end_in (soap=0x7ffff7fbe010, tag1=0x7ffff7fdb228 "EncryptedKey", tag2=0x5555556048c6 "ds:KeyInfo") at ../../plugin/wsseapi.c:7318
    #3  0x00005555555d6512 in soap_element_end_in (soap=0x7ffff7fbe010, tag=0x5555556048c6 "ds:KeyInfo") at ../../stdsoap2.c:14022
    #4  0x000055555559ff73 in soap_in_ds__KeyInfoType (soap=0x7ffff7fbe010, tag=0x5555556048c6 "ds:KeyInfo", a=0x555555855080, type=0x555555603cc0 "") at soapC.c:19442
    #5  0x00005555555b61c7 in soap_in_PointerTo_ds__KeyInfo (soap=0x7ffff7fbe010, tag=0x5555556048c6 "ds:KeyInfo", a=0x555555850df8, type=0x555555603cc0 "") at soapC.c:26085
    #6  0x000055555559f506 in soap_in_xenc__EncryptedKeyType (soap=0x7ffff7fbe010, tag=0x555555606990 "xenc:EncryptedKey", a=0x555555850df0, type=0x5555556047b1 "xenc:EncryptedKeyType")
        at soapC.c:19252
    #7  0x00005555555b9844 in soap_in_PointerToxenc__EncryptedKeyType (soap=0x7ffff7fbe010, tag=0x555555606990 "xenc:EncryptedKey", a=0x555555848060,
        type=0x5555556047b1 "xenc:EncryptedKeyType") at soapC.c:27117
    #8  0x000055555559fd8a in soap_in_ds__KeyInfoType (soap=0x7ffff7fbe010, tag=0x5555556048c6 "ds:KeyInfo", a=0x555555848060, type=0x555555603cc0 "") at soapC.c:19400
    #9  0x00005555555b61c7 in soap_in_PointerTo_ds__KeyInfo (soap=0x7ffff7fbe010, tag=0x5555556048c6 "ds:KeyInfo", a=0x555555850b68, type=0x555555603cc0 "") at soapC.c:26085
    #10 0x000055555559f506 in soap_in_xenc__EncryptedKeyType (soap=0x7ffff7fbe010, tag=0x555555606990 "xenc:EncryptedKey", a=0x555555850b60, type=0x5555556047b1 "xenc:EncryptedKeyType")
        at soapC.c:19252
    #11 0x00005555555b9844 in soap_in_PointerToxenc__EncryptedKeyType (soap=0x7ffff7fbe010, tag=0x555555606990 "xenc:EncryptedKey", a=0x55555582a420,
        type=0x5555556047b1 "xenc:EncryptedKeyType") at soapC.c:27117
    #12 0x000055555559fd8a in soap_in_ds__KeyInfoType (soap=0x7ffff7fbe010, tag=0x5555556048c6 "ds:KeyInfo", a=0x55555582a420, type=0x555555603cc0 "") at soapC.c:19400
    #13 0x00005555555b61c7 in soap_in_PointerTo_ds__KeyInfo (soap=0x7ffff7fbe010, tag=0x5555556048c6 "ds:KeyInfo", a=0x555555855148, type=0x555555603cc0 "") at soapC.c:26085
    #14 0x000055555559f506 in soap_in_xenc__EncryptedKeyType (soap=0x7ffff7fbe010, tag=0x555555606990 "xenc:EncryptedKey", a=0x555555855140, type=0x5555556047b1 "xenc:EncryptedKeyType")
        at soapC.c:19252
    #15 0x00005555555b9844 in soap_in_PointerToxenc__EncryptedKeyType (soap=0x7ffff7fbe010, tag=0x555555606990 "xenc:EncryptedKey", a=0x55555584f608,
        type=0x5555556047b1 "xenc:EncryptedKeyType") at soapC.c:27117
    #16 0x000055555557e959 in soap_in__wsse__Security (soap=0x7ffff7fbe010, tag=0x55555560487e "wsse:Security", a=0x55555584f5f0, type=0x555555603cc0 "") at soapC.c:9498
    #17 0x00005555555a8e39 in soap_in_PointerTo_wsse__Security (soap=0x7ffff7fbe010, tag=0x55555560487e "wsse:Security", a=0x55555584f4f0, type=0x555555603cc0 "") at soapC.c:22092
    #18 0x000055555557dba4 in soap_in_SOAP_ENV__Header (soap=0x7ffff7fbe010, tag=0x555555603cb0 "SOAP-ENV:Header", a=0x55555584f4f0, type=0x0) at soapC.c:9262
    #19 0x000055555555dbd4 in soap_getheader (soap=0x7ffff7fbe010) at soapC.c:29
    #20 0x00005555555e85a7 in soap_recv_header (soap=0x7ffff7fbe010) at ../../stdsoap2.c:21204
    #21 0x00005555555e61d5 in soap_begin_serve (soap=0x7ffff7fbe010) at ../../stdsoap2.c:20487
    #22 0x00005555555bb14c in soap_serve (soap=0x7ffff7fbe010) at soapServer.c:32
    #23 0x000055555555b405 in main (argc=3, argv=0x7fffffffe4a8) at wstdemo.c:186
    

**Timeline**

2020-11-05 - Vendor Disclosure  
2020-12-16 - Vendor advised patch released on 2020-11-20  
2021-01-05 - Public Release

Discovered by a member of Cisco Talos.

CVE-2020-13574: TALOS-2020-1185 || Cisco Talos Intelligence Group

A code execution vulnerability exists in the WS-Addressing plugin functionality of Genivia gSOAP 2.8.107. A specially crafted SOAP request can lead to remote code execution. An attacker can send an HTTP request to trigger this vulnerability.

**Summary**

A code execution vulnerability exists in the WS-Addressing plugin functionality of Genivia gSOAP 2.8.107. A specially crafted SOAP request can lead to remote code execution. An attacker can send an HTTP request to trigger this vulnerability.

**Tested Versions**

Genivia gSOAP 2.8.107

**Product URLs**

https://www.genivia.com/products.html#gsoap

**CVSSv3 Score**

9.8 - CVSS:3.0/AV:N/AC:L/PR:N/UI:N/S:U/C:H/I:H/A:H

**CWE**

CWE-680 - Integer Overflow to Buffer Overflow

**Details**

The gSOAP toolkit is a C/C++ library for developing XML-based web services. It includes several plugins to support the implementation of SOAP and web service standards. The framework also provides multiple deployment options including modules for both IIS and Apache, standalone CGI scripts and its own standalone HTTP service.

One of the many plugins provided by gSOAP includes the wsa plugin for supporting the WS-Addressing specification which provides an asynchronous mechanism for routing SOAP requests and responses. The specification includes a element for providing URI parameters to a number of different parts of both requests and responses. The URIs may include a username and password for the resource in a standard format. http://user:password@somehost.com A buffer overflow vulnerability existing in the parsing of these extra parameters.

It starts by looking for the : in the uri and assumes that if it’s not part of :// that is is the seperator between the username and password.

    21234   s = strchr(endpoint, ':');
    21235   if (s && s[1] == '/' && s[2] == '/') // Skip the :// part of the parameter
    21236     s += 3;
    21237   else // Assume it's the seperator and start from the beginning of the element
    21238     s = endpoint;  
    

Processing continues by trying to find the @ to seperate the user:pass from the hostname. At this point, parsing of the username and password occurs assuming we have found both seperators (@ and :)

    21240   t = strchr(s, '@'); // attempts to find the seperator 
    21241
    21242   if (t && *s != ':' && *s != '@')
    21243   {
    21244     size_t l = t - s + 1;  // Calculate the size of the user:pass part of the string
    21245     char *r = (char*)soap_malloc(soap, l); // Allocate enough storage to hold both the user and pass
    21246     n = s - endpoint;
    21247     if (r)
    21248     {
    21249       s = soap_decode(r, l, s, ":@");  // s is still pointing to the beginning of the data in this element
    21250       soap->userid = r; // r is now a copy of the user part of the string up to the :
    21251       soap->passwd = SOAP_STR_EOS;
    21252       if (*s == ':') // s now points to the : seperator
    21253       {
    21254         s++; // Step past the seperator and now we should be pointing to the password section
    21255         if (*s != '@') // Make sure the password isn't empty
    21256         {
    21257           l = t - s + 1; // t points to the @ seperator so here we calculate the length of the password by subtracting between the two seperators
    21258           r = r + strlen(r) + 1; // r currently points to the copied username so we skip past to copy the password into the same buffer.
    21259           s = soap_decode(r, l, s, "@"); // l is now a very large number allowing us to write us much data to the head as we like and cleanly terminate the copy with an @
    21260           soap->passwd = r;
    21261         }
    21262       }
    21263     }
    21264     s++;
    21265     soap_strcpy(soap->endpoint + n, sizeof(soap->endpoint) - n, s);
    21266   }
    

Here the code makes an assumption about the order of the : and @ seperators. It assumes that the @ (t) is after :(s) and calculates the size for the second soap\_decode based on this assumption. If the : comes after the @, this calculation causes the calculated size to be negative and wrap around and become a very large length value to soap_decode to parse the password.

Within soap\_decode, an attempt to copy the data into a the new heap buffer occurs. As the length is a very large number and the counter is counting backwards, we are able to write an arbitrary amount of data past our destination buffer.

    7919 soap_decode(char *buf, size_t len, const char *val, const char *sep)
    7920 {
    7921   const char *s;
    7922   char *t = buf;
    7923   size_t i = len;
    7924   for (s = val; *s; s++)
    7925     if (*s != ' ' && *s != '\t' && !strchr(sep, *s))
    7926       break;
    7927   if (len > 0)
    7928   {
    7929     if (*s == '"')
    7930     {
    7931       s++;
    7932  
    7933       while (*s && *s != '"' && --i)
    7934         *t++ = *s++;
    7935     }
    

**Crash Information**

    Starting program: /gsoap-2.8/gsoap/samples/wsa/wsademo 8080
    [Thread debugging using libthread_db enabled]
    Using host libthread_db library "/lib/x86_64-linux-gnu/libthread_db.so.1".
    Server is running
    malloc(): memory corruption
    
    Program received signal SIGABRT, Aborted.
    __GI_raise (sig=sig@entry=6) at ../sysdeps/unix/sysv/linux/raise.c:51
    51	../sysdeps/unix/sysv/linux/raise.c: No such file or directory.
    (gdb) bt
    #0  __GI_raise (sig=sig@entry=6) at ../sysdeps/unix/sysv/linux/raise.c:51
    #1  0x00007ffff70af8b1 in __GI_abort () at abort.c:79
    #2  0x00007ffff70f8907 in __libc_message (action=action@entry=do_abort, fmt=fmt@entry=0x7ffff7225dfa "%s\n") at ../sysdeps/posix/libc_fatal.c:181
    #3  0x00007ffff70ff97a in malloc_printerr (str=str@entry=0x7ffff722406e "malloc(): memory corruption") at malloc.c:5350
    #4  0x00007ffff7103a04 in _int_malloc (av=av@entry=0x7ffff745ac40 <main_arena>, bytes=bytes@entry=72) at malloc.c:3738
    #5  0x00007ffff710616c in __GI___libc_malloc (bytes=72) at malloc.c:3057
    #6  0x000055555556ddae in soap_malloc (soap=soap@entry=0x7ffff7fba010, n=56, n@entry=48) at stdsoap2_ssl.c:10428
    #7  0x000055555556de7f in soap_strdup (soap=soap@entry=0x7ffff7fba010, s=s@entry=0x555555589430 "http://www.w3.org/2005/08/addressing/soap/fault") at stdsoap2_ssl.c:2806
    #8  0x000055555557eedd in soap_try_connect_command (soap=soap@entry=0x7ffff7fba010, http_command=http_command@entry=2000,
        endpoint=endpoint@entry=0x55555579db40 "http://%@AAAA:", 'B' <repeats 186 times>..., action=action@entry=0x555555589430 "http://www.w3.org/2005/08/addressing/soap/fault")
        at stdsoap2_ssl.c:21486
    #9  0x0000555555582cdb in soap_connect_command (soap=soap@entry=0x7ffff7fba010, http_command=http_command@entry=2000,
        endpoints=0x55555579db40 "http://%@AAAA:", 'B' <repeats 186 times>..., action=0x555555589430 "http://www.w3.org/2005/08/addressing/soap/fault") at stdsoap2_ssl.c:21455
    #10 0x0000555555582de0 in soap_connect (soap=soap@entry=0x7ffff7fba010, endpoint=<optimized out>, action=<optimized out>) at stdsoap2_ssl.c:21408
    #11 0x0000555555562ebb in soap_wsa_fault_subcode_action (soap=soap@entry=0x7ffff7fba010, flag=flag@entry=1, faultsubcode=faultsubcode@entry=0x555555589856 "wsa5:ActionNotSupported",
        faultstring=faultstring@entry=0x555555589d50 "The [action] cannot be processed at the receiver.", faultdetail=faultdetail@entry=0x0, action=action@entry=0x0)
        at ../../plugin/wsaapi.c:1088
    #12 0x0000555555563145 in soap_wsa_fault_subcode (faultdetail=0x0, faultstring=0x555555589d50 "The [action] cannot be processed at the receiver.",
        faultsubcode=0x555555589856 "wsa5:ActionNotSupported", flag=1, soap=0x7ffff7fba010) at ../../plugin/wsaapi.c:1022
    #13 soap_wsa_sender_fault_subcode (faultdetail=0x0, faultstring=0x555555589d50 "The [action] cannot be processed at the receiver.", faultsubcode=0x555555589856 "wsa5:ActionNotSupported",
        soap=0x7ffff7fba010) at ../../plugin/wsaapi.c:1126
    #14 soap_wsa_error (soap=soap@entry=0x7ffff7fba010, fault=fault@entry=wsa5__ActionNotSupported, info=0x0) at ../../plugin/wsaapi.c:1428
    #15 0x0000555555563a7d in soap_wsa_set_error (soap=0x7ffff7fba010, c=0x55555579bbf0, s=0x55555579bc20) at ../../plugin/wsaapi.c:1623
    #16 0x000055555558535f in soap_set_fault (soap=soap@entry=0x7ffff7fba010) at stdsoap2_ssl.c:22051
    #17 0x00005555555861f3 in soap_send_fault (soap=0x7ffff7fba010) at stdsoap2_ssl.c:22314
    #18 0x00005555555588f3 in main (argc=2, argv=<optimized out>) at wsademo.c:85
    

**Timeline**

2020-11-05 - Vendor Disclosure  
2020-12-16 - Vendor advised patch released on 2020-11-20  
2021-01-05 - Public Release

Discovered by a member of Cisco Talos.

CVE-2020-13576: TALOS-2020-1187 || Cisco Talos Intelligence Group

Firejail before 0.9.64.4 allows attackers to bypass intended access restrictions because there is a TOCTOU race condition between a stat operation and an OverlayFS mount operation.

@@ -1,6 +1,6 @@ #! /bin/sh # Guess values for system-dependent variables and create Makefiles. # Generated by GNU Autoconf 2.69 for firejail 0.9.64.2. # Generated by GNU Autoconf 2.69 for firejail 0.9.64.4. # # Report bugs to <netblue30@protonmail.com>. # @@ -580,8 +580,8 @@ MAKEFLAGS= # Identity of this package. PACKAGE\_NAME='firejail' PACKAGE\_TARNAME='firejail' PACKAGE\_VERSION='0.9.64.2' PACKAGE\_STRING='firejail 0.9.64.2' PACKAGE\_VERSION='0.9.64.4' PACKAGE\_STRING='firejail 0.9.64.4' PACKAGE\_BUGREPORT='netblue30@protonmail.com' PACKAGE\_URL='https://firejail.wordpress.com'  
@@ -711,7 +711,6 @@ enable\_option\_checking enable\_analyzer enable\_apparmor enable\_dbusproxy enable\_overlayfs enable\_usertmpfs enable\_man enable\_firetunnel @@ -1294,7 +1293,7 @@ if test "$ac\_init\_help" = "long"; then # Omit some internal or obsolete options to make the list less imposing. # This message is too long to be a string in the A/UX 3.1 sh. cat <<\_ACEOF \\\`configure' configures firejail 0.9.64.2 to adapt to many kinds of systems. \\\`configure' configures firejail 0.9.64.4 to adapt to many kinds of systems. Usage: $0 \[OPTION\]... \[VAR=VALUE\]... @@ -1356,7 +1355,7 @@ fi  
if test -n "$ac\_init\_help"; then case $ac\_init\_help in short | recursive ) echo "Configuration of firejail 0.9.64.2:";; short | recursive ) echo "Configuration of firejail 0.9.64.4:";; esac cat <<\\\_ACEOF @@ -1367,7 +1366,6 @@ Optional Features: \--enable-analyzer enable GCC 10 static analyzer \--enable-apparmor enable apparmor \--disable-dbusproxy disable dbus proxy \--disable-overlayfs disable overlayfs \--disable-usertmpfs disable tmpfs as regular user \--disable-man disable man pages \--disable-firetunnel disable firetunnel @@ -1473,7 +1471,7 @@ fi test -n "$ac\_init\_help" && exit $ac\_status if $ac\_init\_version; then cat <<\\\_ACEOF firejail configure 0.9.64.2 firejail configure 0.9.64.4 generated by GNU Autoconf 2.69 Copyright (C) 2012 Free Software Foundation, Inc. @@ -1775,7 +1773,7 @@ cat >config.log <<\_ACEOF This file contains any messages produced by compilers while running configure, to aid debugging if configure makes a mistake. It was created by firejail $as\_me 0.9.64.2, which was It was created by firejail $as\_me 0.9.64.4, which was generated by GNU Autoconf 2.69. Invocation command line was $ $0 $@ @@ -3530,18 +3528,16 @@ if test "x$enable\_dbusproxy" != "xno"; then :  
fi  
# overlayfs features temporarely disabled pending fixes HAVE\_OVERLAYFS="" # Check whether --enable-overlayfs was given. if test "${enable\_overlayfs+set}" = set; then : enableval=$enable\_overlayfs; fi  
if test "x$enable\_overlayfs" !\= "xno"; then :  
HAVE\_OVERLAYFS="\-DHAVE\_OVERLAYFS"  
  
fi # #AC\_ARG\_ENABLE(\[overlayfs\], # AS\_HELP\_STRING(\[--disable-overlayfs\], \[disable overlayfs\])) #AS\_IF(\[test "x$enable\_overlayfs" != "xno"\], \[ # HAVE\_OVERLAYFS="-DHAVE\_OVERLAYFS" # AC\_SUBST(HAVE\_OVERLAYFS) #\])  
HAVE\_USERTMPS="" # Check whether --enable-usertmpfs was given. @@ -4817,7 +4813,7 @@ cat >>$CONFIG\_STATUS <<\\\_ACEOF || ac\_write\_fail=1 \# report actual input values of CONFIG\_FILES etc. instead of their \# values after options handling. ac\_log=" This file was extended by firejail $as\_me 0.9.64.2, which was This file was extended by firejail $as\_me 0.9.64.4, which was generated by GNU Autoconf 2.69. Invocation command line was CONFIG\_FILES = $CONFIG\_FILES @@ -4871,7 +4867,7 @@ \_ACEOF cat >>$CONFIG\_STATUS <<\_ACEOF || ac\_write\_fail=1 ac\_cs\_config="\`$as\_echo "$ac\_configure\_args" | sed 's/^ //; s/\[\\\\""\\\`\\$\]/\\\\\\\\&/g'\`" ac\_cs\_version="\\\\ firejail config.status 0.9.64.2 firejail config.status 0.9.64.4 configured by $0, generated by GNU Autoconf 2.69, with options \\\\"\\$ac\_cs\_config\\\\"

CVE-2021-26910: disabled overlayfs, 0.9.64.4 testing · netblue30/firejail@97d8a03

Go before 1.14.14 and 1.15.x before 1.15.7 on Windows is vulnerable to Command Injection and remote code execution when using the "go get" command to fetch modules that make use of cgo (for example, cgo can execute a gcc program from an untrusted download).

**The Go Blog**

Today’s Go security release fixes an issue involving PATH lookups in untrusted directories that can lead to remote execution during the go get command. We expect people to have questions about what exactly this means and whether they might have issues in their own programs. This post details the bug, the fixes we have applied, how to decide whether your own programs are vulnerable to similar problems, and what you can do if they are.

**Go command & remote execution**

One of the design goals for the go command is that most commands – including go build, go doc, go get, go install, and go list – do not run arbitrary code downloaded from the internet. There are a few obvious exceptions: clearly go run, go test, and go generate _do_ run arbitrary code – that’s their job. But the others must not, for a variety of reasons including reproducible builds and security. So when go get can be tricked into executing arbitrary code, we consider that a security bug.

If go get must not run arbitrary code, then unfortunately that means all the programs it invokes, such as compilers and version control systems, are also inside the security perimeter. For example, we’ve had issues in the past in which clever use of obscure compiler features or remote execution bugs in version control systems became remote execution bugs in Go. (On that note, Go 1.16 aims to improve the situation by introducing a GOVCS setting that allows configuration of exactly which version control systems are allowed and when.)

Today’s bug, however, was entirely our fault, not a bug or obscure feature of gcc or git. The bug involves how Go and other programs find other executables, so we need to spend a little time looking at that before we can get to the details.

**Commands and PATHs and Go**

All operating systems have a concept of an executable path ($PATH on Unix, %PATH% on Windows; for simplicity, we’ll just use the term PATH), which is a list of directories. When you type a command into a shell prompt, the shell looks in each of the listed directories, in turn, for an executable with the name you typed. It runs the first one it finds, or it prints a message like “command not found.”

On Unix, this idea first appeared in Seventh Edition Unix’s Bourne shell (1979). The manual explained:

> The shell parameter $PATH defines the search path for the directory containing the command. Each alternative directory name is separated by a colon (:). The default path is :/bin:/usr/bin. If the command name contains a / then the search path is not used. Otherwise, each directory in the path is searched for an executable file.

Note the default: the current directory (denoted here by an empty string, but let’s call it “dot”) is listed ahead of /bin and /usr/bin. MS-DOS and then Windows chose to hard-code that behavior: on those systems, dot is always searched first, automatically, before considering any directories listed in %PATH%.

As Grampp and Morris pointed out in their classic paper “UNIX Operating System Security” (1984), placing dot ahead of system directories in the PATH means that if you cd into a directory and run ls, you might get a malicious copy from that directory instead of the system utility. And if you can trick a system administrator to run ls in your home directory while logged in as root, then you can run any code you want. Because of this problem and others like it, essentially all modern Unix distributions set a new user’s default PATH to exclude dot. But Windows systems continue to search dot first, no matter what PATH says.

For example, when you type the command

    go version
    

on a typically-configured Unix, the shell runs a go executable from a system directory in your PATH. But when you type that command on Windows, cmd.exe checks dot first. If .\go.exe (or .\go.bat or many other choices) exists, cmd.exe runs that executable, not one from your PATH.

For Go, PATH searches are handled by exec.LookPath, called automatically by exec.Command. And to fit well into the host system, Go’s exec.LookPath implements the Unix rules on Unix and the Windows rules on Windows. For example, this command

    out, err := exec.Command("go", "version").CombinedOutput()
    

behaves the same as typing go version into the operating system shell. On Windows, it runs .\go.exe when that exists.

(It is worth noting that Windows PowerShell changed this behavior, dropping the implicit search of dot, but cmd.exe and the Windows C library SearchPath function continue to behave as they always have. Go continues to match cmd.exe.)

**The Bug**

When go get downloads and builds a package that contains import "C", it runs a program called cgo to prepare the Go equivalent of the relevant C code. The go command runs cgo in the directory containing the package sources. Once cgo has generated its Go output files, the go command itself invokes the Go compiler on the generated Go files and the host C compiler (gcc or clang) to build any C sources included with the package. All this works well. But where does the go command find the host C compiler? It looks in the PATH, of course. Luckily, while it runs the C compiler in the package source directory, it does the PATH lookup from the original directory where the go command was invoked:

    cmd := exec.Command("gcc", "file.c")
    cmd.Dir = "badpkg"
    cmd.Run()
    

So even if badpkg\gcc.exe exists on a Windows system, this code snippet will not find it. The lookup that happens in exec.Command does not know about the badpkg directory.

The go command uses similar code to invoke cgo, and in that case there’s not even a path lookup, because cgo always comes from GOROOT:

    cmd := exec.Command(GOROOT+"/pkg/tool/"+GOOS_GOARCH+"/cgo", "file.go")
    cmd.Dir = "badpkg"
    cmd.Run()
    

This is even safer than the previous snippet: there’s no chance of running any bad cgo.exe that may exist.

But it turns out that cgo itself also invokes the host C compiler, on some temporary files it creates, meaning it executes this code itself:

    // running in cgo in badpkg dir
    cmd := exec.Command("gcc", "tmpfile.c")
    cmd.Run()
    

Now, because cgo itself is running in badpkg, not in the directory where the go command was run, it will run badpkg\gcc.exe if that file exists, instead of finding the system gcc.

So an attacker can create a malicious package that uses cgo and includes a gcc.exe, and then any Windows user that runs go get to download and build the attacker’s package will run the attacker-supplied gcc.exe in preference to any gcc in the system path.

Unix systems avoid the problem first because dot is typically not in the PATH and second because module unpacking does not set execute bits on the files it writes. But Unix users who have dot ahead of system directories in their PATH and are using GOPATH mode would be as susceptible as Windows users. (If that describes you, today is a good day to remove dot from your path and to start using Go modules.)

(Thanks to RyotaK for reporting this issue to us.)

**The Fixes**

It’s obviously unacceptable for the go get command to download and run a malicious gcc.exe. But what’s the actual mistake that allows that? And then what’s the fix?

One possible answer is that the mistake is that cgo does the search for the host C compiler in the untrusted source directory instead of in the directory where the go command was invoked. If that’s the mistake, then the fix is to change the go command to pass cgo the full path to the host C compiler, so that cgo need not do a PATH lookup in to the untrusted directory.

Another possible answer is that the mistake is to look in dot during PATH lookups, whether happens automatically on Windows or because of an explicit PATH entry on a Unix system. A user may want to look in dot to find a command they typed in a console or shell window, but it’s unlikely they also want to look there to find a subprocess of a subprocess of a typed command. If that’s the mistake, then the fix is to change the cgo command not to look in dot during a PATH lookup.

We decided both were mistakes, so we applied both fixes. The go command now passes the full host C compiler path to cgo. On top of that, cgo, go, and every other command in the Go distribution now use a variant of the os/exec package that reports an error if it would have previously used an executable from dot. The packages go/build and go/import use the same policy for their invocation of the go command and other tools. This should shut the door on any similar security problems that may be lurking.

Out of an abundance of caution, we also made a similar fix in commands like goimports and gopls, as well as the libraries golang.org/x/tools/go/analysis and golang.org/x/tools/go/packages, which invoke the go command as a subprocess. If you run these programs in untrusted directories – for example, if you git checkout untrusted repositories and cd into them and then run programs like these, and you use Windows or use Unix with dot in your PATH – then you should update your copies of these commands too. If the only untrusted directories on your computer are the ones in the module cache managed by go get, then you only need the new Go release.

After updating to the new Go release, you can update to the latest gopls by using:

    GO111MODULE=on \
    go get golang.org/x/tools/gopls@v0.6.4
    

and you can update to the latest goimports or other tools by using:

    GO111MODULE=on \
    go get golang.org/x/tools/cmd/goimports@v0.1.0
    

You can update programs that depend on golang.org/x/tools/go/packages, even before their authors do, by adding an explicit upgrade of the dependency during go get:

    GO111MODULE=on \
    go get example.com/cmd/thecmd golang.org/x/tools@v0.1.0
    

For programs that use go/build, it is sufficient for you to recompile them using the updated Go release.

Again, you only need to update these other programs if you are a Windows user or a Unix user with dot in the PATH _and_ you run these programs in source directories you do not trust that may contain malicious programs.

**Are your own programs affected?**

If you use exec.LookPath or exec.Command in your own programs, you only need to be concerned if you (or your users) run your program in a directory with untrusted contents. If so, then a subprocess could be started using an executable from dot instead of from a system directory. (Again, using an executable from dot happens always on Windows and only with uncommon PATH settings on Unix.)

If you are concerned, then we’ve published the more restricted variant of os/exec as golang.org/x/sys/execabs. You can use it in your program by simply replacing

    import "os/exec"
    

with

    import exec "golang.org/x/sys/execabs"
    

and recompiling.

**Securing os/exec by default**

We have been discussing on golang.org/issue/38736 whether the Windows behavior of always preferring the current directory in PATH lookups (during exec.Command and exec.LookPath) should be changed. The argument in favor of the change is that it closes the kinds of security problems discussed in this blog post. A supporting argument is that although the Windows SearchPath API and cmd.exe still always search the current directory, PowerShell, the successor to cmd.exe, does not, an apparent recognition that the original behavior was a mistake. The argument against the change is that it could break existing Windows programs that intend to find programs in the current directory. We don’t know how many such programs exist, but they would get unexplained failures if the PATH lookups started skipping the current directory entirely.

The approach we have taken in golang.org/x/sys/execabs may be a reasonable middle ground. It finds the result of the old PATH lookup and then returns a clear error rather than use a result from the current directory. The error returned from exec.Command("prog") when prog.exe exists looks like:

    prog resolves to executable in current directory (.\prog.exe)
    

For programs that do change behavior, this error should make very clear what has happened. Programs that intend to run a program from the current directory can use exec.Command("./prog") instead (that syntax works on all systems, even Windows).

We have filed this idea as a new proposal, golang.org/issue/43724.

CVE-2021-3115: Command PATH security in Go - The Go Programming Language

The sudoedit personality of Sudo before 1.9.5 may allow a local unprivileged user to perform arbitrary directory-existence tests by winning a sudo_edit.c race condition in replacing a user-controlled directory by a symlink to an arbitrary path.

CVE-2021-23239: Stable Release

In x/text in Go before v0.3.5, a "slice bounds out of range" panic occurs in language.ParseAcceptLanguage while processing a BCP 47 tag. (x/text/language is supposed to be able to parse an HTTP Accept-Language header.)

**What version of Go are you using (go version)?**

$ go version
go version go1.15.4 linux/amd64

**Does this issue reproduce with the latest release?****What operating system and processor architecture are you using (go env)?**go env Output  

$ go env
GO111MODULE=""
GOARCH="amd64"
GOBIN=""
GOCACHE="/home/sasha/.cache/go-build"
GOENV="/home/sasha/.config/go/env"
GOEXE=""
GOFLAGS=""
GOHOSTARCH="amd64"
GOHOSTOS="linux"
GOINSECURE=""
GOMODCACHE="/home/sasha/goenv/pkg/mod"
GONOPROXY=""
GONOSUMDB=""
GOOS="linux"
GOPATH="/home/sasha/goenv"
GOPRIVATE=""
GOPROXY="https://proxy.golang.org,direct"
GOROOT="/usr/local/go"
GOSUMDB="sum.golang.org"
GOTMPDIR=""
GOTOOLDIR="/usr/local/go/pkg/tool/linux\_amd64"
GCCGO="gccgo"
AR="ar"
CC="gcc"
CXX="g++"
CGO\_ENABLED="1"
GOMOD=""
CGO\_CFLAGS="-g -O2"
CGO\_CPPFLAGS=""
CGO\_CXXFLAGS="-g -O2"
CGO\_FFLAGS="-g -O2"
CGO\_LDFLAGS="-g -O2"
PKG\_CONFIG="pkg-config"
GOGCCFLAGS="-fPIC -m64 -pthread -fmessage-length=0 -fdebug-prefix-map=/tmp/go-build111267796=/tmp/go-build -gno-record-gcc-switches"
GOROOT/bin/go version: go version go1.15.4 linux/amd64
GOROOT/bin/go tool compile -V: compile version go1.15.4
uname -sr: Linux 4.19.128-microsoft-standard
Distributor ID:	Kali
Description:	Kali GNU/Linux Rolling
Release:	2020.2
Codename:	kali-rolling
/lib/x86\_64-linux-gnu/libc.so.6: GNU C Library (Debian GLIBC 2.31-3) stable release version 2.31.
gdb --version: GNU gdb (Debian 9.2-1) 9.2
**What did you do?**

https://play.golang.org/p/SwAU9tKYRsj

**What did you expect to see?**

Error via return value

**What did you see instead?**

    panic: runtime error: slice bounds out of range [9:8]
    
    goroutine 1 [running]:
    golang.org/x/text/internal/language.(*scanner).resizeRange(0xc000068d08, 0x6, 0x8, 0x3)
    	/tmp/gopath300097471/pkg/mod/golang.org/x/text@v0.3.4/internal/language/parse.go:142 +0x2e7
    golang.org/x/text/internal/language.(*scanner).replace(...)
    	/tmp/gopath300097471/pkg/mod/golang.org/x/text@v0.3.4/internal/language/parse.go:151
    golang.org/x/text/internal/language.parseTag(0xc000068d08, 0x0, 0x0, 0x0, 0xc00007e0a3)
    	/tmp/gopath300097471/pkg/mod/golang.org/x/text@v0.3.4/internal/language/parse.go:296 +0x13b
    golang.org/x/text/internal/language.parseExtension(0xc000068d08, 0x8)
    	/tmp/gopath300097471/pkg/mod/golang.org/x/text@v0.3.4/internal/language/parse.go:552 +0xe74
    golang.org/x/text/internal/language.parseExtensions(0xc000068d08, 0x3030000000000)
    	/tmp/gopath300097471/pkg/mod/golang.org/x/text@v0.3.4/internal/language/parse.go:451 +0xa5
    golang.org/x/text/internal/language.parse(0xc000068d08, 0x4d9210, 0x7, 0x3030000000000, 0x0, 0x0, 0x0, 0x0)
    	/tmp/gopath300097471/pkg/mod/golang.org/x/text@v0.3.4/internal/language/parse.go:268 +0x2bc
    golang.org/x/text/internal/language.Parse(0x4d9210, 0x7, 0x0, 0x0, 0x0, 0x4b1185, 0x4d9210)
    	/tmp/gopath300097471/pkg/mod/golang.org/x/text@v0.3.4/internal/language/parse.go:250 +0x1c7
    golang.org/x/text/language.CanonType.Parse(0x17, 0x4d9210, 0x7, 0x4d9210, 0x7, 0x0, 0x0, 0x3fc0389239a6386c)
    	/tmp/gopath300097471/pkg/mod/golang.org/x/text@v0.3.4/language/parse.go:46 +0x3f
    golang.org/x/text/language.Parse(...)
    	/tmp/gopath300097471/pkg/mod/golang.org/x/text@v0.3.4/language/parse.go:34
    golang.org/x/text/language.ParseAcceptLanguage(0x4d9210, 0x7, 0xc000068f48, 0x442bca, 0x56ed40, 0xc000032778, 0xc000068f78, 0x405e25, 0xc00005e058, 0x0)
    	/tmp/gopath300097471/pkg/mod/golang.org/x/text@v0.3.4/language/parse.go:154 +0x165
    main.main()
    	/tmp/sandbox168582112/prog.go:10   ##+0x3a

CVE-2020-28852: x/text: panic in language.ParseAcceptLanguage while processing bcp47 tag · Issue #42536 · golang/go

Buffer overflow in QUIC dissector in Wireshark 3.4.0 to 3.4.1 allows denial of service via packet injection or crafted capture file

Problems have been found with the following capture file:

https://www.wireshark.org/download/automated/captures/fuzz-2020-12-09-3589621.pcap

stderr:

    Input file: /home/wireshark/menagerie/menagerie/16072-rtcp_transport_cc.pcap
    
    Build host information:
    Linux build1 5.4.0-56-generic #62-Ubuntu SMP Mon Nov 23 19:20:19 UTC 2020 x86_64 x86_64 x86_64 GNU/Linux
    Distributor ID:	Ubuntu
    Description:	Ubuntu 20.04.1 LTS
    Release:	20.04
    Codename:	focal
    
    Buildbot information:
    BUILDBOT_REPOSITORY=git@gitlab.com:wireshark/wireshark.git
    BUILDBOT_WORKERNAME=clang-code-analysis
    BUILDBOT_URL=https://buildbot.wireshark.org/wireshark-master/
    BUILDBOT_BUILDNUMBER=5360
    BUILDBOT_BUILDERNAME=Clang Code Analysis
    BUILDBOT_GOT_REVISION=770746cca810f0979f4b8dc82e2b2f1150f98dcc
    
    Return value:  0
    
    Dissector bug:  0
    
    Valgrind error count:  0
    
    
    
    Latest (but not necessarily the problem) commit:
    770746cca8 epan: Fix format_text treament of Greek, Arabic, etc.
    
    
    Command and args: /home/wireshark/builders/wireshark-master-fuzz/clangcodeanalysis/install.asan/bin/tshark  -nVxr
    =================================================================
    ==3789690==ERROR: AddressSanitizer: stack-buffer-overflow on address 0x7fff2d57a755 at pc 0x5649451bcff6 bp 0x7fff2d57a690 sp 0x7fff2d579e38
    READ of size 73 at 0x7fff2d57a755 thread T0
        #0 0x5649451bcff5 in MemcmpInterceptorCommon(void*, int (*)(void const*, void const*, unsigned long), void const*, void const*, unsigned long) (/home/wireshark/builders/wireshark-master-fuzz/clangcodeanalysis/install.asan/bin/tshark+0x71ff5)
        #1 0x5649451bd4ea in memcmp (/home/wireshark/builders/wireshark-master-fuzz/clangcodeanalysis/install.asan/bin/tshark+0x724ea)
        #2 0x7f4a99e28ac6 in quic_connection_equal /home/wireshark/builders/wireshark-master-fuzz/clangcodeanalysis/build/cmbuild/../epan/dissectors/packet-quic.c:794:39
        #3 0x7f4a99e22b30 in check_dcid_on_coalesced_packet /home/wireshark/builders/wireshark-master-fuzz/clangcodeanalysis/build/cmbuild/../epan/dissectors/packet-quic.c:3260:12
        #4 0x7f4a99e20410 in dissect_quic /home/wireshark/builders/wireshark-master-fuzz/clangcodeanalysis/build/cmbuild/../epan/dissectors/packet-quic.c:3333:14
        #5 0x7f4a9b9a4b21 in call_dissector_through_handle /home/wireshark/builders/wireshark-master-fuzz/clangcodeanalysis/build/cmbuild/../epan/packet.c:720:9
        #6 0x7f4a9b999ad0 in call_dissector_work /home/wireshark/builders/wireshark-master-fuzz/clangcodeanalysis/build/cmbuild/../epan/packet.c:813:9
        #7 0x7f4a9b9a13d0 in call_dissector_only /home/wireshark/builders/wireshark-master-fuzz/clangcodeanalysis/build/cmbuild/../epan/packet.c:3233:8
        #8 0x7f4a9b9515e1 in try_conversation_call_dissector_helper /home/wireshark/builders/wireshark-master-fuzz/clangcodeanalysis/build/cmbuild/../epan/conversation.c:1351:8
        #9 0x7f4a9b95104f in try_conversation_dissector /home/wireshark/builders/wireshark-master-fuzz/clangcodeanalysis/build/cmbuild/../epan/conversation.c:1381:7
        #10 0x7f4a9a49bc47 in decode_udp_ports /home/wireshark/builders/wireshark-master-fuzz/clangcodeanalysis/build/cmbuild/../epan/dissectors/packet-udp.c:652:7
        #11 0x7f4a9a4a4e9e in dissect /home/wireshark/builders/wireshark-master-fuzz/clangcodeanalysis/build/cmbuild/../epan/dissectors/packet-udp.c:1261:5
        #12 0x7f4a9a49ef5d in dissect_udp /home/wireshark/builders/wireshark-master-fuzz/clangcodeanalysis/build/cmbuild/../epan/dissectors/packet-udp.c:1267:3
        #13 0x7f4a9b9a4b21 in call_dissector_through_handle /home/wireshark/builders/wireshark-master-fuzz/clangcodeanalysis/build/cmbuild/../epan/packet.c:720:9
        #14 0x7f4a9b999ad0 in call_dissector_work /home/wireshark/builders/wireshark-master-fuzz/clangcodeanalysis/build/cmbuild/../epan/packet.c:813:9
        #15 0x7f4a9b9993e9 in dissector_try_uint_new /home/wireshark/builders/wireshark-master-fuzz/clangcodeanalysis/build/cmbuild/../epan/packet.c:1413:8
        #16 0x7f4a995ff9bb in ip_try_dissect /home/wireshark/builders/wireshark-master-fuzz/clangcodeanalysis/build/cmbuild/../epan/dissectors/packet-ip.c:1817:7
        #17 0x7f4a99605089 in dissect_ip_v4 /home/wireshark/builders/wireshark-master-fuzz/clangcodeanalysis/build/cmbuild/../epan/dissectors/packet-ip.c:2299:10
        #18 0x7f4a9b9a4b21 in call_dissector_through_handle /home/wireshark/builders/wireshark-master-fuzz/clangcodeanalysis/build/cmbuild/../epan/packet.c:720:9
        #19 0x7f4a9b999ad0 in call_dissector_work /home/wireshark/builders/wireshark-master-fuzz/clangcodeanalysis/build/cmbuild/../epan/packet.c:813:9
        #20 0x7f4a9b9993e9 in dissector_try_uint_new /home/wireshark/builders/wireshark-master-fuzz/clangcodeanalysis/build/cmbuild/../epan/packet.c:1413:8
        #21 0x7f4a9b999ebb in dissector_try_uint /home/wireshark/builders/wireshark-master-fuzz/clangcodeanalysis/build/cmbuild/../epan/packet.c:1437:9
        #22 0x7f4a991c1bfe in dissect_ethertype /home/wireshark/builders/wireshark-master-fuzz/clangcodeanalysis/build/cmbuild/../epan/dissectors/packet-ethertype.c:292:21
        #23 0x7f4a9b9a4b21 in call_dissector_through_handle /home/wireshark/builders/wireshark-master-fuzz/clangcodeanalysis/build/cmbuild/../epan/packet.c:720:9
        #24 0x7f4a9b999ad0 in call_dissector_work /home/wireshark/builders/wireshark-master-fuzz/clangcodeanalysis/build/cmbuild/../epan/packet.c:813:9
        #25 0x7f4a9b9a13d0 in call_dissector_only /home/wireshark/builders/wireshark-master-fuzz/clangcodeanalysis/build/cmbuild/../epan/packet.c:3233:8
        #26 0x7f4a9b995b04 in call_dissector_with_data /home/wireshark/builders/wireshark-master-fuzz/clangcodeanalysis/build/cmbuild/../epan/packet.c:3246:8
        #27 0x7f4a991be72b in dissect_eth_common /home/wireshark/builders/wireshark-master-fuzz/clangcodeanalysis/build/cmbuild/../epan/dissectors/packet-eth.c:568:5
        #28 0x7f4a991bd197 in dissect_eth /home/wireshark/builders/wireshark-master-fuzz/clangcodeanalysis/build/cmbuild/../epan/dissectors/packet-eth.c:861:5
        #29 0x7f4a9b9a4b21 in call_dissector_through_handle /home/wireshark/builders/wireshark-master-fuzz/clangcodeanalysis/build/cmbuild/../epan/packet.c:720:9
        #30 0x7f4a9b999ad0 in call_dissector_work /home/wireshark/builders/wireshark-master-fuzz/clangcodeanalysis/build/cmbuild/../epan/packet.c:813:9
        #31 0x7f4a9b9a13d0 in call_dissector_only /home/wireshark/builders/wireshark-master-fuzz/clangcodeanalysis/build/cmbuild/../epan/packet.c:3233:8
        #32 0x7f4a9924ea42 in dissect_frame /home/wireshark/builders/wireshark-master-fuzz/clangcodeanalysis/build/cmbuild/../epan/dissectors/packet-frame.c:788:6
        #33 0x7f4a9b9a4b21 in call_dissector_through_handle /home/wireshark/builders/wireshark-master-fuzz/clangcodeanalysis/build/cmbuild/../epan/packet.c:720:9
        #34 0x7f4a9b999ad0 in call_dissector_work /home/wireshark/builders/wireshark-master-fuzz/clangcodeanalysis/build/cmbuild/../epan/packet.c:813:9
        #35 0x7f4a9b9a13d0 in call_dissector_only /home/wireshark/builders/wireshark-master-fuzz/clangcodeanalysis/build/cmbuild/../epan/packet.c:3233:8
        #36 0x7f4a9b995b04 in call_dissector_with_data /home/wireshark/builders/wireshark-master-fuzz/clangcodeanalysis/build/cmbuild/../epan/packet.c:3246:8
        #37 0x7f4a9b9952f9 in dissect_record /home/wireshark/builders/wireshark-master-fuzz/clangcodeanalysis/build/cmbuild/../epan/packet.c:594:3
        #38 0x7f4a9b965118 in epan_dissect_run_with_taps /home/wireshark/builders/wireshark-master-fuzz/clangcodeanalysis/build/cmbuild/../epan/epan.c:598:2
        #39 0x56494528215b in process_packet_single_pass /home/wireshark/builders/wireshark-master-fuzz/clangcodeanalysis/build/cmbuild/../tshark.c:3806:5
        #40 0x564945285ab6 in process_cap_file_single_pass /home/wireshark/builders/wireshark-master-fuzz/clangcodeanalysis/build/cmbuild/../tshark.c:3460:9
        #41 0x56494527f490 in process_cap_file /home/wireshark/builders/wireshark-master-fuzz/clangcodeanalysis/build/cmbuild/../tshark.c:3616:26
        #42 0x5649452791c0 in main /home/wireshark/builders/wireshark-master-fuzz/clangcodeanalysis/build/cmbuild/../tshark.c:2057:16
        #43 0x7f4a8eb750b2 in __libc_start_main /build/glibc-ZN95T4/glibc-2.31/csu/../csu/libc-start.c:308:16
        #44 0x5649451a641d in _start (/home/wireshark/builders/wireshark-master-fuzz/clangcodeanalysis/install.asan/bin/tshark+0x5b41d)
    
    Address 0x7fff2d57a755 is located in stack of thread T0 at offset 53 in frame
        #0 0x7f4a99e224df in check_dcid_on_coalesced_packet /home/wireshark/builders/wireshark-master-fuzz/clangcodeanalysis/build/cmbuild/../epan/dissectors/packet-quic.c:3226
    
      This frame has 1 object(s):
        [32, 53) 'dcid' (line 3229) <== Memory access at offset 53 overflows this variable
    HINT: this may be a false positive if your program uses some custom stack unwind mechanism, swapcontext or vfork
          (longjmp and C++ exceptions *are* supported)
    SUMMARY: AddressSanitizer: stack-buffer-overflow (/home/wireshark/builders/wireshark-master-fuzz/clangcodeanalysis/install.asan/bin/tshark+0x71ff5) in MemcmpInterceptorCommon(void*, int (*)(void const*, void const*, unsigned long), void const*, void const*, unsigned long)
    Shadow bytes around the buggy address:
      0x100065aa7490: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00
      0x100065aa74a0: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00
      0x100065aa74b0: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00
      0x100065aa74c0: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00
      0x100065aa74d0: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00
    =>0x100065aa74e0: 00 00 00 00 f1 f1 f1 f1 00 00[05]f3 f3 f3 f3 f3
      0x100065aa74f0: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00
      0x100065aa7500: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00
      0x100065aa7510: 00 00 00 00 00 00 00 00 f1 f1 f1 f1 00 00 05 f2
      0x100065aa7520: f2 f2 f2 f2 00 00 05 f2 f2 f2 f2 f2 f8 f2 f8 f2
      0x100065aa7530: f8 f8 f8 f2 f2 f2 f2 f2 f8 f8 f8 f2 f2 f2 f2 f2
    Shadow byte legend (one shadow byte represents 8 application bytes):
      Addressable:           00
      Partially addressable: 01 02 03 04 05 06 07
      Heap left redzone:       fa
      Freed heap region:       fd
      Stack left redzone:      f1
      Stack mid redzone:       f2
      Stack right redzone:     f3
      Stack after return:      f5
      Stack use after scope:   f8
      Global redzone:          f9
      Global init order:       f6
      Poisoned by user:        f7
      Container overflow:      fc
      Array cookie:            ac
      Intra object redzone:    bb
      ASan internal:           fe
      Left alloca redzone:     ca
      Right alloca redzone:    cb
      Shadow gap:              cc
    ==3789690==ABORTING

_no debug trace_

CVE-2020-26422: Buildbot crash output: fuzz-2020-12-09-3589621.pcap (#17073) · Issues · Wireshark Foundation / wireshark · GitLab

Memory leak in the dissection engine in Wireshark 3.4.0 allows denial of service via packet injection or crafted capture file.

Problems have been found with the following capture file:

https://www.wireshark.org/download/automated/captures/fuzz-2020-11-19-20476.pcap

stderr:

    Input file: /home/wireshark/menagerie/menagerie/xrite-i1displaypro-i1profiler.pcap.gz
    
    Build host information:
    Linux build6 4.15.0-122-generic #124-Ubuntu SMP Thu Oct 15 13:03:05 UTC 2020 x86_64 x86_64 x86_64 GNU/Linux
    Distributor ID:	Ubuntu
    Description:	Ubuntu 18.04.5 LTS
    Release:	18.04
    Codename:	bionic
    
    Buildbot information:
    BUILDBOT_WORKERNAME=clang-code-analysis
    BUILDBOT_BUILDNUMBER=5344
    BUILDBOT_BUILDERNAME=Clang Code Analysis
    BUILDBOT_URL=https://buildbot.wireshark.org/wireshark-master/
    BUILDBOT_REPOSITORY=git@gitlab.com:wireshark/wireshark.git
    BUILDBOT_GOT_REVISION=1d7bc367e943464f912a67ad436fabddb1a61a37
    
    Return value:  0
    
    Dissector bug:  0
    
    Valgrind error count:  1
    
    
    
    Latest (but not necessarily the problem) commit:
    1d7bc367e9 GSM A Common: Dissect polygon points
    
    
    Command and args: ./tools/valgrind-wireshark.sh -b /home/wireshark/builders/wireshark-master-fuzz/clangcodeanalysis/install.plain/bin  -T
    ==10764== Memcheck, a memory error detector
    ==10764== Copyright (C) 2002-2017, and GNU GPL'd, by Julian Seward et al.
    ==10764== Using Valgrind-3.13.0 and LibVEX; rerun with -h for copyright info
    ==10764== Command: /home/wireshark/builders/wireshark-master-fuzz/clangcodeanalysis/install.plain/bin/tshark -Vx -nr /fuzz/buildbot/clangcodeanalysis/valgrind-fuzz/fuzz-2020-11-19-20476.pcap
    ==10764==
    ==10764==
    ==10764== HEAP SUMMARY:
    ==10764==     in use at exit: 597,877 bytes in 8,905 blocks
    ==10764==   total heap usage: 2,023,536 allocs, 2,014,631 frees, 157,450,596 bytes allocated
    ==10764==
    ==10764== LEAK SUMMARY:
    ==10764==    definitely lost: 556,928 bytes in 8,702 blocks
    ==10764==    indirectly lost: 0 bytes in 0 blocks
    ==10764==      possibly lost: 0 bytes in 0 blocks
    ==10764==    still reachable: 40,154 bytes in 172 blocks
    ==10764==         suppressed: 795 bytes in 31 blocks
    ==10764== Rerun with --leak-check=full to see details of leaked memory
    ==10764==
    ==10764== For counts of detected and suppressed errors, rerun with: -v
    ==10764== ERROR SUMMARY: 0 errors from 0 contexts (suppressed: 0 from 0)
    Definitely + indirectly (556928 + 0) exceeds max (102400).

_no debug trace_

CVE-2020-26419: Buildbot crash output: fuzz-2020-11-19-20476.pcap (#17032) · Issues · Wireshark Foundation / wireshark · GitLab

An exploitable use-after-free vulnerability exists in WebKitGTK browser version 2.30.1 x64. A specially crafted HTML web page can cause a use-after-free condition, resulting in a remote code execution. The victim needs to visit a malicious web site to trigger this vulnerability.

Tag

#c++