Project

General

Profile

Actions

Bug #7318

open

flow: flow timeout pseudo packet triggers unexpected alert

Added by Jason Ish about 1 month ago. Updated 3 days ago.

Status:
In Review
Priority:
Normal
Assignee:
Target version:
Affected Versions:
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


Subtasks 1 (1 open0 closed)

Bug #7368: flow: flow timeout pseudo packet triggers unexpected alert (7.0.x backport)AssignedVictor JulienActions
Actions #1

Updated by Philippe Antoine about 1 month 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 #2

Updated by Jason Ish about 1 month 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 #3

Updated by Juliana Fajardini Reichow about 1 month ago

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

Actions #4

Updated by Jason Ish about 1 month 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 #5

Updated by Victor Julien 20 days ago

  • Status changed from New to Assigned
  • Assignee changed from OISF Dev to Victor Julien
  • Target version changed from TBD to 8.0.0-beta1
  • Label Needs backport to 7.0 added
Actions #6

Updated by OISF Ticketbot 20 days ago

  • Subtask #7368 added
Actions #7

Updated by OISF Ticketbot 20 days ago

  • Label deleted (Needs backport to 7.0)
Actions #8

Updated by Victor Julien 3 days ago

  • Status changed from Assigned to In Review
Actions

Also available in: Atom PDF