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
