The get-ip-range package before 4.0.0 for Node.js is vulnerable to denial of service (DoS) if the range is untrusted input. An attacker could send a large range (such as 128.0.0.0/1) that causes resource exhaustion.

@@ -2,6 +2,9 @@ import { toLong, fromLong } from 'ip'; // @ts\-ignore import { Address4, Address6 } from 'ip-address';  
// Set default max range let maxRange \= 10000;  
const getIPv4 \= (ip: string): Address4 | null \=> { try { return new Address4(ip); @@ -24,6 +27,13 @@ const getRangev4 = (ip1: string, ip2: string) => { let firstAddressLong \= toLong(ip1); const lastAddressLong \= toLong(ip2);  
const totalIPs \= lastAddressLong \- firstAddressLong;  
// Prevent DoS if (totalIPs \> maxRange) { throw new Error(\`Too many IPs in range. Total number: ${totalIPs}. Max count is ${maxRange}, to increase, set the limit with the MAX\_RANGE environment variable\`) }  
for (firstAddressLong; firstAddressLong <= lastAddressLong; firstAddressLong++) ips.push(fromLong(firstAddressLong));  
@@ -48,6 +58,8 @@ const isCIDR = (ipCIDR: Address4 | Address6): boolean => Boolean(ipCIDR.parsedSu const isRange \= (ipRange: string): boolean \=> ipRange.indexOf('-') !== \-1;  
const getIPRange \= (ip1: string, ip2?: string): Array<string\> \=> { maxRange \= parseInt(process.env.MAX\_RANGE || '10000');  
const ip1v4 \= getIPv4(ip1); const ip1v6 \= getIPv6(ip1);

CVE-2021-27191: limit total IPs in range to avoid DoS · JoeScho/get-ip-range@98ca22b

An out-of-bounds write vulnerability exists in the Obj.cpp load_obj() functionality of Prusa Research PrusaSlicer 2.2.0 and Master (commit 4b040b856). A specially crafted obj file can lead to code execution. An attacker can provide a malicious file to trigger this vulnerability.

CVE-2020-28595: TALOS-2020-1219 || Cisco Talos Intelligence Group

A stack-based buffer overflow vulnerability exists in the Objparser::objparse() functionality of Prusa Research PrusaSlicer 2.2.0 and Master (commit 4b040b856). A specially crafted obj file can lead to code execution. An attacker can provide a malicious file to trigger this vulnerability.

**Summary**

A stack-based buffer overflow vulnerability exists in the Objparser::objparse() functionality of Prusa Research PrusaSlicer 2.2.0 and Master (commit 4b040b856). A specially crafted obj file can lead to code execution. An attacker can provide a malicious file to trigger this vulnerability.

**Tested Versions**

Prusa Research PrusaSlicer 2.2.0  
Prusa Research PrusaSlicer Master (commit 4b040b856)

**Product URLs**

https://www.prusa3d.com/prusaslicer/

**CVSSv3 Score**

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

**CWE**

CWE-121 - Stack-based Buffer Overflow

**Details**

Prusa Slicer is an open-source 3-D printer slicing program forked off Slic3r that can convert various 3-D model file formats and can output corresponding 3-D printer-readable Gcode.

One of the input file formats PrusaSlicer can deal with is .obj files, the code mainly handling this can be found in PrusaSlicer/src/libslic3r/Format/OBJ.cpp and PrusaSlicer/src/libslic3r/Format/objparser.cpp. We now proceed to trace the code-path from entry to vulnerability:

    bool load_obj(const char *path, TriangleMesh *meshptr){
        if(meshptr == nullptr) return false;
    
        // Parse the OBJ file.
        ObjParser::ObjData data;
        if (! ObjParser::objparse(path, data)) {   // [1]
            //    die "Failed to parse $file\n" if !-e $path;
            return false;
        }
        // [...]
    

At \[1\], we provide a path to a .obj file, which is then processed into the ObjParser::ObjData object, which we will examine the structure of when needed. Continuing into ObjParser::objparse:

    bool objparse(const char *path, ObjData &data)
    {
        FILE *pFile = boost::nowide::fopen(path, "rt");
        if (pFile == 0)
            return false;
    
        try {
            char buf[65536 * 2];  // [1]
            size_t len = 0;
            size_t lenPrev = 0;
            while ((len = ::fread(buf + lenPrev, 1, 65536, pFile)) != 0) { // [2]
                len += lenPrev;
                size_t lastLine = 0;
                for (size_t i = 0; i < len; ++ i)
                    if (buf[i] == '\r' || buf[i] == '\n') {
                        buf[i] = 0;
                        char *c = buf + lastLine;
                        while (*c == ' ' || *c == '\t')
                            ++ c;
                        obj_parseline(c, data);
                        lastLine = i + 1;
                    }
                lenPrev = len - lastLine; //  
                memmove(buf, buf + lastLine, lenPrev);
            }
        }
        catch (std::bad_alloc&) {
            printf("Out of memory\r\n");
        }
        ::fclose(pFile);
    
        // printf("vertices: %d\r\n", data.vertices.size() / 4);
        // printf("coords: %d\r\n", data.coordinates.size());
        return true;
    }
    

At \[2\] we can clearly see the call to fread reading into a fixed-size stack buffer at \[1\] inside of a while loop that is completely at the input file’s behest, resulting in a stack-based buffer overflow that can lead to arbitrary code execution.

**Crash Information**

    =================================================================
    ==593876==ERROR: AddressSanitizer: stack-buffer-overflow on address 0x7fff5b94fd80 at pc 0x0000004d3521 bp 0x7fff5b92fc70 sp 0x7fff5b92f438
    WRITE of size 12928 at 0x7fff5b94fd80 thread T0
        #0 0x4d3520 in fread (/root/boop/assorted_fuzzing/prusaslicer/obj_fuzzdir/fuzzobj.bin+0x4d3520)
        #1 0x7f2f2ceb7a94 in ObjParser::objparse(char const*, ObjParser::ObjData&) boop/assorted_fuzzing/prusaslicer/PrusaSlicer/src/libslic3r/Format/objparser.cpp:332:17
    
    Address 0x7fff5b94fd80 is located in stack of thread T0 at offset 131104 in frame
        #0 0x7f2f2ceb78af in ObjParser::objparse(char const*, ObjParser::ObjData&) /boop/assorted_fuzzing/prusaslicer/PrusaSlicer/src/libslic3r/Format/objparser.cpp:323
    
      This frame has 1 object(s):
        [32, 131104) 'buf' (line 329) <== Memory access at offset 131104 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 (/boop/assorted_fuzzing/prusaslicer/obj_fuzzdir/fuzzobj.bin+0x4d3520) in fread
    Shadow bytes around the buggy address:
      0x10006b721f60: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00
      0x10006b721f70: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00
      0x10006b721f80: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00
      0x10006b721f90: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00
      0x10006b721fa0: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00
    =>0x10006b721fb0:[f3]f3 f3 f3 f3 f3 f3 f3 f3 f3 f3 f3 f3 f3 f3 f3
      0x10006b721fc0: f3 f3 f3 f3 f3 f3 f3 f3 f3 f3 f3 f3 f3 f3 f3 f3
      0x10006b721fd0: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00
      0x10006b721fe0: 00 00 00 00 f1 f1 f1 f1 00 00 00 00 00 00 00 00
      0x10006b721ff0: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00
      0x10006b722000: 00 00 00 00 00 00 00 f2 f2 f2 f2 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
    ==593876==ABORTING
    

**Timeline**

2020-12-14 - Vendor disclosure  
2021-01-14 - Vendor patched  
2021-04-21 - Public release

Discovered by Lilith >\_> of Cisco Talos.

CVE-2020-28596: TALOS-2020-1220 || Cisco Talos Intelligence Group

A denial-of-service vulnerability exists in the WS-Addressing 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-Addressing 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 wsa plugin for supporting the WS-Addressing specification which provides an asynchronous mechanism for routing SOAP requests and responses. The specification includes a element to allow the request to specify a fault endpoint. A denial of service condition can occur if a request includes a FaultTo element but doesn't include an Address element as well.

A normal request

      <wsa5:FaultTo SOAP-ENV:mustUnderstand="1">
       <wsa5:Address></wsa5:Address> <---
       <wsa5:ReferenceParameters>
        <chan:ChannelInstance>0</chan:ChannelInstance>
       </wsa5:ReferenceParameters>
       <wsa5:Metadata>
       </wsa5:Metadata>
      </wsa5:FaultTo>
    

A malicious request

      <wsa5:FaultTo SOAP-ENV:mustUnderstand="1">
       <wsa5:ReferenceParameters>
        <chan:ChannelInstance>0</chan:ChannelInstance>
       </wsa5:ReferenceParameters>
       <wsa5:Metadata>
       </wsa5:Metadata>
      </wsa5:FaultTo>
    

FaultTo->Address is set but never checked to be valid.

    1055     if (oldheader->SOAP_WSA(FaultTo))
    1056       oldheader->SOAP_WSA(FaultTo)->Address = oldheader->SOAP_WSA(ReplyTo)->Address;
    1057   }
    

No check of oldheader->SOAP\_WSA(FaultTo)->Address is ever made before being used.

    1058   /* use FaultTo */
    1059   if (oldheader && oldheader->SOAP_WSA(FaultTo) &&** !strcmp(oldheader->SOAP_WSA(FaultTo)->Address, soap_wsa_noneURI)) **
    1060     return soap_send_empty_response(soap, SOAP_OK);     /* HTTP ACCEPTED */
    1061   soap->header = NULL;
    

**Crash Information**

    (gdb) r 8080
    Starting program: /gsoap-2.8-wsa/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
    
    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  0x000055555556637a in soap_wsa_fault_subcode_action (soap=0x7ffff7fbe010, flag=1, faultsubcode=0x5555555a9739 "wsa5:ActionNotSupported",
        faultstring=0x5555555a9c80 "The [action] cannot be processed at the receiver.", faultdetail=0x0, action=0x0) at ../../plugin/wsaapi.c:1060
    #2  0x0000555555566257 in soap_wsa_fault_subcode (soap=0x7ffff7fbe010, flag=1, faultsubcode=0x5555555a9739 "wsa5:ActionNotSupported",
        faultstring=0x5555555a9c80 "The [action] cannot be processed at the receiver.", faultdetail=0x0) at ../../plugin/wsaapi.c:1022
    #3  0x00005555555666b1 in soap_wsa_sender_fault_subcode (soap=0x7ffff7fbe010, faultsubcode=0x5555555a9739 "wsa5:ActionNotSupported",
        faultstring=0x5555555a9c80 "The [action] cannot be processed at the receiver.", faultdetail=0x0) at ../../plugin/wsaapi.c:1128
    #4  0x0000555555566d5d in soap_wsa_error (soap=0x7ffff7fbe010, fault=wsa5__ActionNotSupported, info=0x0) at ../../plugin/wsaapi.c:1430
    #5  0x000055555556709e in soap_wsa_set_error (soap=0x7ffff7fbe010, c=0x5555557bdbc0, s=0x5555557bdbc8) at ../../plugin/wsaapi.c:1625
    #6  0x00005555555a61f4 in soap_set_fault (soap=0x7ffff7fbe010) at stdsoap2_ssl.c:22059
    #7  0x00005555555a6f2a in soap_send_fault (soap=0x7ffff7fbe010) at stdsoap2_ssl.c:22322
    #8  0x00005555555650cf in soap_serve (soap=0x7ffff7fbe010) at soapServer.c:42
    #9  0x0000555555558d44 in main (argc=2, argv=0x7fffffffe4c8) 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-13575: TALOS-2020-1186 || Cisco Talos Intelligence Group

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. While procesing a RequestSecurityToken request, a denial of service condition can be triggered when processing XML namespaces. If the namespace was previuosly included and has no value, a null pointer dereference can occur.

    13866   if ((soap->mode & SOAP_XML_CANONICAL))
    13867   {
    13868     /* push namespace */
    13869     if (!strncmp(name, "xmlns", 5) && ((name[5] == ':') || name[5] == '\0'))
    13870     {
    13871       (void)soap_push_ns(soap, name + 5 + (name[5] == ':'), value, 0, 0); <------ value is null and never checked before being saved.
    13872       if (name[5] == '\0')
    13873         soap_utilize_ns(soap, SOAP_STR_EOS, 0);
    13874       else if (soap->c14ninclude && ((*soap->c14ninclude == '*' || soap_tagsearch(soap->c14ninclude, name + 6))))
    13875         soap_utilize_ns(soap, name, 0);
    13876     }
    

**Crash Information**

    Starting program: /gsoap-2.8/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:174
    174	../sysdeps/x86_64/multiarch/../strcmp.S: No such file or directory.
    (gdb) bt
    #0  __strcmp_ssse3 () at ../sysdeps/x86_64/multiarch/../strcmp.S:174
    #1  0x00005555555b25f8 in soap_push_ns (soap=soap@entry=0x7ffff7fba010, id=0x55555583ef16 "SOAP-ENV", ns=ns@entry=0x0, utilized=utilized@entry=0, isearly=isearly@entry=0)
        at ../../stdsoap2.c:12677
    #2  0x00005555555b614d in soap_attribute (soap=soap@entry=0x7ffff7fba010, name=<optimized out>, name@entry=0x55555583ef10 "xmlns:SOAP-ENV", value=0x0) at ../../stdsoap2.c:13871
    #3  0x00005555555ca19f in soap_out_xsd__anyType (soap=soap@entry=0x7ffff7fba010, tag=0x555555837150 "wst:RequestSecurityToken", tag@entry=0x0, id=id@entry=0, node=node@entry=0x55555583ebb0,
        type=type@entry=0x0) at ../../dom.c:461
    #4  0x00005555555c9ed7 in soap_out_xsd__anyType (soap=soap@entry=0x7ffff7fba010, tag=0x55555583eac0 "SOAP-ENV:Body", tag@entry=0x0, id=id@entry=0, node=node@entry=0x55555583ea30,
        type=type@entry=0x0) at ../../dom.c:484
    #5  0x00005555555d1a26 in soap_wsse_verify_digest (soap=soap@entry=0x7ffff7fba010, alg=alg@entry=19, canonical=canonical@entry=1, id=<optimized out>,
        hash=hash@entry=0x7fffffffe0b0 "\260~\207\367\060") at ../../plugin/wsseapi.c:4276
    #6  0x00005555555d1e54 in soap_wsse_verify_SignedInfo (soap=soap@entry=0x7ffff7fba010) at ../../plugin/wsseapi.c:4161
    #7  0x00005555555d2180 in soap_wsse_verify_Signature (soap=soap@entry=0x7ffff7fba010) at ../../plugin/wsseapi.c:3845
    #8  0x00005555555d33ac in soap_wsse_preparefinalrecv (soap=0x7ffff7fba010) at ../../plugin/wsseapi.c:7659
    #9  0x00005555555c10b8 in soap_end_recv (soap=soap@entry=0x7ffff7fba010) at ../../stdsoap2.c:11512
    #10 0x00005555555a54e4 in soap_serve___wst__RequestSecurityToken (soap=soap@entry=0x7ffff7fba010) at soapServer.c:95
    #11 0x00005555555a5b0e in soap_serve_request (soap=soap@entry=0x7ffff7fba010) at soapServer.c:62
    #12 0x00005555555a5ba0 in soap_serve (soap=0x7ffff7fba010) at soapServer.c:37
    #13 0x000055555555af35 in main (argc=<optimized out>, argv=0x7fffffffe448) 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-13577: TALOS-2020-1188 || 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 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.

Tag

#c++