Project

General

Profile

Actions

Bug #4821

closed

xbits: no error on invalid 'expire' values

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

Status:
Rejected
Priority:
Normal
Assignee:
Target version:
Affected Versions:
Effort:
Difficulty:
Label:

Description

alert http any any -> any any (msg:"TEST - No Error")"; flow:established,to_server; http.method; content:"GET"; xbits:set,ET.2020_8260.1,track ip_src,expire 10,noalert; sid:1;)
alert http any any -> any any (msg:"TEST - Error")"; flow:established,to_server; http.method; content:"GET"; xbits:set,ET.2020_8260.1,noalert,track ip_src,expire 10; sid:2;)
alert http any any -> any any (msg:"TEST - No Error")"; flow:established,to_server; http.method; content:"GET"; xbits:set,ET.2020_8260.1,track ip_src,expire 10,asdf; sid:3;)

only sid 2 produces an error, despite that all 3 sids should be considered "invalid"

Error Produced by sid:2

[1539] 27/10/2021 -- 21:58:51 - (detect-xbits.c:208) <Error> (DetectXbitParse) -- [ERRCODE: SC_ERR_PCRE_MATCH(2)] - "set,ET.2020_8260.1,noalert,track ip_src,expire 10" is not a valid setting for xbits.

I'd also add that the documentation is a bit vague on the proper use of the noalert keyword in relation to xbits. It currently reads

To not alert, use noalert;

I suggest adding a bit of context which indicates it should be a standalone keyword in the rule and not an "option" to the xbits keyword.


Related issues 1 (1 open0 closed)

Copied from Suricata - Bug #4786: xbits: no error on invalid 'expire' valuesAssignedShivani BhardwajActions
Actions #1

Updated by Jeff Lucovsky almost 3 years ago

  • Copied from Bug #4786: xbits: no error on invalid 'expire' values added
Actions #2

Updated by Jeff Lucovsky almost 3 years ago

  • Target version changed from 5.0.8 to 5.0.9
Actions #3

Updated by Shivani Bhardwaj almost 3 years ago

  • Assignee changed from Jeff Lucovsky to Shivani Bhardwaj
Actions #4

Updated by Shivani Bhardwaj over 2 years ago

  • Assignee changed from Shivani Bhardwaj to Jeff Lucovsky

The fix will have to be backported from 6.0.x and not master

Actions #5

Updated by Victor Julien over 2 years ago

  • Priority changed from High to Normal
  • Target version changed from 5.0.9 to 5.0.10
Actions #6

Updated by Victor Julien over 2 years ago

  • Status changed from Assigned to Rejected

5.0.x is close to EOL, so not fixing this minor issue.

Actions

Also available in: Atom PDF