Project

General

Profile

Bug #608

engine address parsing issue with negation

Added by Anoop Saldanha about 7 years ago. Updated about 2 months ago.

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

Description

Address [192.168.0.0/16,!192.168.1.0/24,192.168.1.1] is parsed as

192.168.0.0 - 192.168.0.255, 192.168.2.0-192.168.255.255

instead of

192.168.0.0 - 192.168.0.255, 192.168.1.1 - 192.168.1.1, 192.168.2.0 - 192.168.255.255

Issue comes up when negated addresses are mixed with non-negated addresses.

History

#1

Updated by Victor Julien about 7 years ago

  • Target version changed from 1.4beta2 to 1.4beta3
#2

Updated by Victor Julien about 7 years ago

  • Target version changed from 1.4beta3 to 1.4rc1
#3

Updated by Anoop Saldanha almost 7 years ago

  • Target version changed from 1.4rc1 to 1.4beta2

The fix for #599(https://github.com/inliniac/suricata/pull/223) exposes this bug, which fails 2 unittests(now disabled).

Unittests would be renabled when we fix this bug.

#4

Updated by Victor Julien almost 7 years ago

  • Target version changed from 1.4beta2 to 2.0rc2
#5

Updated by Victor Julien almost 6 years ago

  • Target version changed from 2.0rc2 to 2.0rc1
#6

Updated by Victor Julien almost 6 years ago

  • Target version changed from 2.0rc1 to 2.0.1rc1
#7

Updated by Victor Julien over 5 years ago

  • Assignee changed from Anoop Saldanha to OISF Dev
  • Target version changed from 2.0.1rc1 to 2.0.2
#8

Updated by Victor Julien over 5 years ago

  • Target version changed from 2.0.2 to 2.0.3
#9

Updated by Victor Julien over 5 years ago

  • Target version changed from 2.0.3 to 2.0.4
#10

Updated by Victor Julien about 5 years ago

  • Target version changed from 2.0.4 to 3.0RC2
#11

Updated by Victor Julien about 4 years ago

  • Target version changed from 3.0RC2 to Soon
#12

Updated by Philippe Antoine 6 months ago

That would make the list order dependent which is not the case right now.
So, I do not know if the expected behavior will be clear to everyone.

Should we go for another syntax like
(192.168.0.0/16 - 192.168.1.0/24) + 192.168.1.1
Then we should issue warnings when we do not have enough parenthesis as operations are not commutative...

#13

Updated by Andreas Herz about 2 months ago

Hmm we could force a syntax that requires all negation coming at the end so it's easier to parse and calculate?

#14

Updated by Victor Julien about 2 months ago

  • Target version changed from Soon to TBD

I don't think we can risk breaking existing setups/expectations.

#15

Updated by Andreas Herz about 2 months ago

Would you suggest a more advanced parsing?

Also available in: Atom PDF