Project

General

Profile

Actions

Bug #5077

closed

byte_math rule options need to be in order or will fail otherwise

Added by Andreas Herz about 2 years ago. Updated over 1 year ago.

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

Description

If a rule write doesn't follow the order in the table of https://suricata.readthedocs.io/en/latest/rules/payload-keywords.html#byte-math it will run into a parsing error

alert tcp any any -> any any (msg:"Byte-math test"; ipv4.hdr; byte_math:bytes 4, offset 72, oper +, rvalue 77, endian little, result result_val; tcp.hdr; byte_test: 1, =, 0x88, 1, relative; sid:1;)

results in

<Error> - [ERRCODE: SC_ERR_PCRE_PARSE(7)] - byte_math parse error; invalid value: ret -1, string "bytes 4, offset 72, oper +, rvalue 77, endian little, result result_val" 

while the correct order works

alert tcp any any -> any any (msg:"Byte-math test"; ipv4.hdr; byte_math:bytes 4, offset 72, oper +, rvalue 77, result result_val, endian little; tcp.hdr; byte_test: 1, =, 0x88, 1, relative; sid:1;)

The test rules swap the endian and result option.

The root cause is IMHO the regex used in src/detect-bytemath.c

Actions #1

Updated by Jeff Lucovsky about 2 years ago

  • Status changed from Assigned to In Review
Actions #2

Updated by Victor Julien over 1 year ago

  • Target version changed from TBD to 7.0.0-beta1
Actions #3

Updated by Jeff Lucovsky over 1 year ago

  • Status changed from In Review to Closed
Actions

Also available in: Atom PDF