Project

General

Profile

Actions

Bug #4962

closed

Run stream reassembly on both directions upon receiving a FIN packet

Added by Jeff Lucovsky almost 3 years ago. Updated over 2 years ago.

Status:
Closed
Priority:
Normal
Target version:
Affected Versions:
Effort:
Difficulty:
Label:

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

ftp-active.pcap (400 KB) ftp-active.pcap Angelo Mirabella, 12/07/2021 12:24 PM
suricata.yaml (29.8 KB) suricata.yaml Angelo Mirabella, 12/07/2021 12:24 PM
test.rule (318 Bytes) test.rule Angelo Mirabella, 12/07/2021 12:24 PM

Related issues 1 (0 open1 closed)

Copied from Suricata - Bug #4877: Run stream reassembly on both directions upon receiving a FIN packetClosedAngelo MirabellaActions
Actions #1

Updated by Jeff Lucovsky almost 3 years ago

  • Copied from Bug #4877: Run stream reassembly on both directions upon receiving a FIN packet added
Actions #2

Updated by Shivani Bhardwaj over 2 years ago

  • Status changed from Assigned to Closed
Actions

Also available in: Atom PDF