Security #7657: tcp: syn resend with different seq leads to detection bypasss - Suricata - Open Information Security Foundation

Actions

Copy link

Security #7657

closed

AM VJ

tcp: syn resend with different seq leads to detection bypasss

Security #7657: tcp: syn resend with different seq leads to detection bypasss

Added by Angelo Mirabella about 1 year ago. Updated 7 months ago.

Status:

Closed

Priority:

Normal

Assignee:

Victor Julien

Target version:

8.0.1

Affected Versions:

8.0.0

Label:

CVE:

2025-59147

Git IDs:

Severity:

HIGH

Disclosure Date:

Description

When performing SYN flooding, followed by an HTTP transaction, suricata is not able to detect the application layer protocol, leading to a false negative.

Tested in latest master with default configuration.
Attaching signature (test.rule) and 2 pcaps: syn_flood.pcapng and exploit.pcapng.

The first one contains the SYN flooding + HTTP transaction that should trigger the signature (but it does not trigger).
The second one contains only the HTTP transaction and correctly triggers the signature.

Files

Download all files

test.rule (1.05 KB) test.rule		Angelo Mirabella, 04/11/2025 02:48 PM
exploit.pcapng (2.79 KB) exploit.pcapng		Angelo Mirabella, 04/11/2025 02:48 PM
syn_flood.pcapng (4.81 KB) syn_flood.pcapng		Angelo Mirabella, 04/11/2025 02:48 PM

Subtasks 1 (0 open — 1 closed)

AM Updated by Angelo Mirabella 10 months ago Actions
Copy link
#1

Hi, any update on this?

VJ Updated by Victor Julien 10 months ago Actions
Copy link
#2

Subject changed from Suricata is not able to detect the app layer protocol when performing SYN flooding to tcp: syn resend with different seq leads to detection bypasss
Status changed from New to Assigned
Assignee changed from OISF Dev to Victor Julien
Target version changed from TBD to 8.0.1
Private changed from No to Yes

It looks like the generic session reuse logic doesn't handle syn resends, as it is supposed to be handled by the regular logic at the syn_sent state. However, the logic there to handle resends seems to ignore the sequence number (isn), so it's not leading to a correct matching up of the last syn (pkt 24) and the syn/ack that matches it.