Project

General

Profile

Actions

Bug #5766

open

Misparsing of DNP3 g70v1 objects and failed reassembly

Added by Alex Lasky over 1 year ago. Updated over 1 year ago.

Status:
New
Priority:
Normal
Assignee:
Target version:
Affected Versions:
Effort:
Difficulty:
Label:
Needs backport to 6.0

Description

Suricata misparses the attached three-fragment g70v1 DNP3 file download. As a result no alerts are generated in eve.json, and reassembly of DNP3 frames into DNP3 fragments is truncated after 498, 249 and 249 bytes respectively for each of the three fragments based on lua diagnostic output for #args["buffer"].

There are 2 issues here:
a) Incorrect parsing of DNP3 g70v1 objects; and
b) Regardless of the preprocessor's inability to parse the DNP3 object, the dnp3_data buffer should still be complete, as correct reassembly of DNP3 frames does not depend on application layer parsing.

Update 2022-12-23: Further testing shows that the truncated dnp3_data buffer has nothing to do with the DNP3 object within it. The problem was also seen with non-legacy file downloads. The truncation was confirmed using the isdataat:1800 keyword with no dnp3 keywords other than dnp3_data. Very occasionally, the fragment does get fully reassembled, but I can't see an obvious pattern to explain why. The attached packet_log.lua script works reliably in reassembling and logging g70v1 file downloads from TCP packet payloads, showing that the bug is in the DNP3 fragment reassembly code and is not caused by Suricata failing to see the traffic.


Files

elegy.pcapng (7.98 KB) elegy.pcapng Alex Lasky, 12/20/2022 04:08 AM
DNP3_slave_diags.txt (24.4 KB) DNP3_slave_diags.txt Alex Lasky, 12/20/2022 04:08 AM
packet_log.lua (3.28 KB) packet_log.lua Alex Lasky, 12/23/2022 06:24 AM
Actions #1

Updated by Alex Lasky over 1 year ago

Actions

Also available in: Atom PDF