Bug #5766
Updated by Alex Lasky almost 2 years ago
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.