Bug #4877
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 Philippe Antoine almost 3 years ago
- Status changed from New to In Review
- Target version set to 7.0.0-beta1
Updated by Philippe Antoine almost 3 years ago
- Label Needs backport to 5.0, Needs backport to 6.0 added
Updated by Jeff Lucovsky almost 3 years ago
- Copied to Bug #4962: Run stream reassembly on both directions upon receiving a FIN packet added
Updated by Jeff Lucovsky almost 3 years ago
- Copied to Bug #4963: Run stream reassembly on both directions upon receiving a FIN packet added
Updated by Victor Julien almost 3 years ago
- Status changed from In Review to Closed
41a139b590a059171d0517a455c562486e1a21c2