Project

General

Profile

Actions
Copy link

Bug #7318

open

flow: flow timeout pseudo packet triggers unexpected alert

Added by Jason Ish 22 days ago. Updated 14 days ago.

Status:
New
Priority:
Normal
Assignee:
OISF Dev
Target version:
TBD
Affected Versions:
7.0.7, git master
Effort:
Difficulty:
Label:

Description

Given the following rules:

alert tcp any any -> $EXTERNAL_NET 443 (flow: to_server; flags: S,CE; flowbits:set, tls_tracker; flowbits: noalert; sid:09901001; )
alert tcp any any -> $EXTERNAL_NET 443 (flowbits:isset, tls_tracker; content: "|15 03 01 00 02 02|"; startswith; flowbits:set, tls_error; sid:09901031; rev:1; msg:"TLS 1.2 Fatal Alert (outgoing packet)"; )
alert tcp $EXTERNAL_NET 443 -> any any (flowbits:isset, tls_tracker; content: "|15 03 01 00 02 02|"; startswith; flowbits:set, tls_error; sid:09901032; rev:1; msg:"TLS 1.2 Fatal Alert (incoming packet)"; )
alert tcp any any -> $EXTERNAL_NET 443 (flow: to_server; flowbits:isset, tls_error; sid:09901033; rev:1; msg:"Allow TLS error handling (outgoing packet)"; )
alert tcp $EXTERNAL_NET 443 -> any any (flow: to_client; flowbits:isset, tls_error; sid:09901034; rev:1; msg:"Allow TLS error handling (incoming packet)"; )

and the attached PCAP, the last alert in the output is for SID 9901033, but with a timestamp of the first packet in the stream. This is a pseudo-packet generated for the purpose of finishing up any transactions on flow end, as it is determined the TLS transaction is not yet complete.

However, the alert, given the timestamp being reported doesn't make much sense and likely shouldn't be triggered.

A SV test to show this behavior has been created: https://github.com/OISF/suricata-verify/pull/2080

Actions
Copy link
 #1

Updated by Philippe Antoine 21 days ago

Is not there potentially 2 bugs ?

- first the timeout of the alert with a pseudo packet timing out
- do we want the second alert at all ? Like should flowbits set SIG_FLAG_REQUIRE_PACKET ?

Actions
Copy link
 #2

Updated by Jason Ish 21 days ago

Philippe Antoine wrote in #note-1:

Is not there potentially 2 bugs ?

- first the timeout of the alert with a pseudo packet timing out
- do we want the second alert at all ? Like should flowbits set SIG_FLAG_REQUIRE_PACKET ?

Possibly, but I haven't looked into those possibilities yet.

Actions
Copy link
 #3

Updated by Juliana Fajardini Reichow 17 days ago

It seems that the pcap was not attached to the ticket. Is it the same as seen in the SV test?

Actions
Copy link
 #4

Updated by Jason Ish 14 days ago

Philippe Antoine wrote in #note-1:

- do we want the second alert at all ? Like should flowbits set SIG_FLAG_REQUIRE_PACKET ?

Naively setting this flag for flowbits does appear to work for this specific case but does break a number of S-V tests.

However, setting the mask SIG_MASK_REQUIRE_REAL_PKT doesn't result in any test breakage and fixes the issue, but I'm not sure if there are any edge cases I'm missing given this mask is used for tests on real packets, where I think flowbits could apply to re-assembled data as well.

Actions
Copy link

Also available in: Atom PDF