Bug #4963
closedRun stream reassembly on both directions upon receiving a FIN packet
Description
Suricata invokes the stream reassembly logic only for the current packet direction if the packet contains a FIN flag. However, this does not handle the case in which the packet ACKs data from the opposing direction.
Pcap, configuration and rule files to reproduce the issue are attached.
The pcap performs 2 file downloads ("notepad.exe" and "test.pdf") via the commands "STOR" and "RETR".
We expect the sha256 hashes for the two fileinfo events generated for each file to be the same. However, in the case of the "test.pdf" file, the fileinfo event generated by the "RETR" command has a wrong hash due to the last chunk not being processed by the stream reassembly engine because of the above bug.
The packet with the FIN and ACK flags set is packet 400 in the pcap.
Expected "test.pdf" hash: 7d400735ff3054837da5d92a10ad2faa8b6825f100dc167a6b008e753015b382
Obtained "test.pdf" hashes: 7d400735ff3054837da5d92a10ad2faa8b6825f100dc167a6b008e753015b382 f7c7d7a890e94023b1c5fae718f017b4e4a1ab13c4db06417c96289759c0bf84 (wrong)
Files
Updated by Jeff Lucovsky almost 3 years ago
- Copied from Bug #4877: Run stream reassembly on both directions upon receiving a FIN packet added
Updated by Jeff Lucovsky over 2 years ago
- Status changed from Assigned to Closed
Included in commit 7cd0d00fdc1e9c1a6b4049379f23b5fa3b368a04
in master-5.0.x