Packets generated using softflowd break the parser

[arckoor]

I have a v9 packet generated by softflowd, command line was sudo ./softflowd -v 9 -i any -n 127.0.0.1:2055 -D -T full -P udp -m 200 -t general=300s: bad_packet.pcapng.gz (Use wireshark to examine) Parsing that completely breaks the parser. During debugging I found a couple of problems:

• v9_loopup.rs:260 - this should be Ipv6DstAddr instead of Ipv4DstAddr
• softflowd doesn't use padding, or at least doesn't align the packets to 32 bit boundaries. If an Option-Data packet with uneven length is encountered, this check will fail, adding 1 to total_length (which is 0 at this point), thus returning 1. There aren't any bytes left, so parsing will fail. I locally fixed this by changing the line to if length % 2 == 0 || total_length == 0, but I don't really know it this is a good solution.
• Packtes that include both templates and data can overrun a Flowset boundary. I've copied the packet bytes to rust arrays, and split them into their individual flowsets to make debugging easier. All the code I used to debug this is available here, with a couple of hopefully helpful comments. The tl;dr is that the first flowset, which is a Data-Template is successfully parsed. It first reads the flowset id (0), then the length (72), the template id (1024), and finally the count (16). It then parses those 16 entries. The nom parser then invokes itself again, running into the next flowset, where it reads the flowset id, but interprets it as the template id. It similarly reads the length (64), but interprets it as the count. It then tries to parse 64 entries, which are 4 bytes each. If the packet is only made up of Data-/Option-Templates, which are usually at most 5 in total, the packet comes out to ~200 bytes, which is less than nom tries to parse (4*64 = 256). This means the parser will error out, returning what it successfully parsed (the first flowset / template), along with the rest, which starts precisely at the next flowset. Then the outer loop continues, this time parsing the array as a flowset instead of a template, flowset id and length are consumed correctly and the whole thing works. However, if there are Data flowsets after the Templates, the packet is significantly longer (here ~800) bytes, longer than 256. That means the nom parser will not error out on the first go-around, producing a template with wildly incorrect values, leading to a panic as the parser will try to access something like index 54000 in a 500 element slice.

For debugging, I added [nom(DeriveDebug)] to certain structs, and inserted the dumped impl-Blocks directly, so I could step through them in an easier way.

I hope this helps, feel free to reach out if my descriptions don't make sense :p

[mikemiles-dev]

Thanks for the pcap. I will look into this.

[mikemiles-dev]

https://github.com/mikemiles-dev/netflow_parser/pull/59

[mikemiles-dev]

I reworked how we are handling padding, can you retest with this branch?

[arckoor]

I just did, it was able to run through a roughly 2 day capture done with softflowd without a single panic. I also compared the branch to main performance wise, I didn't see any significant change (though I did just eyeball it :p). Good job and thank you very much!