CVE-2023-2906: Wireshark CP2179 Parsing Divide By Zero DoS
AHA! has discovered a deinal-of-service issue with [Wireshark] from The Wireshark Foundation, and is issuing this disclosure in accordance with AHA!’s standard disclosure policy today, on Thursday, August 24, 2023. CVE-2023-2906 has been assigned to this issue.
Any questions about this disclosure should be directed to [email protected].
Executive Summary
Due to a failure in validating the length provided by an attacker-crafted CP2179 packet, Wireshark versions 2.0.0 through 4.0.7 is susceptible to a divide by zero allowing for a denial of service attack. CVE-2023-2906 appears to be an instance of CWE-369. Note that, according to the patch notes, this effect can only be achieved when a user triggers the vulnerable code patch with the “Decode As…” functionality of Wireshark (or the -d option for tshark), so this vulnerability is unlikely to be triggerable in an automated way.
Technical Details
As can be seen in the below code from the dissect_response_frame function which handles parsing the different types of response frames as part of the SCADA protocol, PG&E 2179 Protocol.
When parsing a TIMETAG_INFO_RESPONSE message, a call is made to the Wireshark function tvb_get_guint8() (on line 723) which retrieves an 8 bit value from the pcap file. If a 0 value is provided within the TIMETAG_INFO_RESPONSE message for the value, a divide by zero error occurs (on line 724).
The relevant code snippet from epan/dissectors/packet-cp2179.c is:
718 case TIMETAG_INFO_RESPONSE:
719 {
720 proto_tree_add_item(cp2179_proto_tree, hf_cp2179_timetag_moredata, tvb, offset, 1, ENC_LITTLE_ENDIAN);
721 proto_tree_add_item(cp2179_proto_tree, hf_cp2179_timetag_numsets, tvb, offset, 1, ENC_LITTLE_ENDIAN);
722
723 num_records = tvb_get_guint8(tvb, offset) & 0x7F;
724 recordsize = (numberofcharacters-1) / num_records;
725 num_values = (recordsize-6) / 2; /* Determine how many 16-bit analog values are present in each event record */
726
727 offset += 1;
Payload
A base64-encoded blob containing the pcap needed to trigger the vulnerability is provided below:
1MOyoQIABAAAAAAAAAAAAP9/AAD6AAAAAAAAAAAAAAAMAAAADAAAAAMAAAADAAAAAAAAAAAAAAAA
AAAAFAAAABQAAAABAAAAAQAAAAEAAAD5/wAAAAAAAAAAAAAAAAAADAAAAAwAAAADAAAAAwAAAAMA
AAAAAAAAAAAAAAwAAAAMAAAAAwAAAAMAAAAAAAAAAAAAAAAAAAAVAAAAFQAAAAMAAAADAAAAAgAA
APn/BACAAAAAAAAAAAAAAAAADAAAAAwAAAADAAAAAwAAAAQAAAA=
Attacker Value
By providing this poisoned set of packets, an attacker could crash the application (Wireshark, tshark, or possibly a custom application utilizing libwireshark) preventing further analysis. Many security appliances capture packets as a matter of course for later analysis, and Wireshark is a common tool used by incident responders. This leads to situations where a specially crafted packet could be used to prevent best incident response practices from taking place.
Credit
This issue is being disclosed through the AHA! CNA and is credited to: zenofex and WanderingGlitch
Timeline
- 2023-05-23 (Thu): Initial findings presented at AHA! Meeting 0x00c8
- 2023-07-08 (Sat): PoC validated and this disclosure drafted.
- 2023-07-17 (Mon): Disclosed to the vendor via email at [email protected] (per the vendor website).
- 2023-07-23 (Sun): Vendor acknowledged the vulnerability in issue 19229.
- 2023-08-23 (Wed): Vendor released fixed version 4.0.8.
- 2023-08-24 (Thu): Public disclosure of CVE-2023-2906.
