Project

General

Profile

Actions
Copy link

Bug #1584

closed

Rule keywords conflict will cause Suricata restart itself in loop

Added by Samiux A about 9 years ago. Updated over 8 years ago.

Status:
Closed
Priority:
High
Assignee:
Andreas Herz
Target version:
3.1rc1
Affected Versions:
Effort:
Difficulty:
Label:

Description

I am running Suricata 2.1dev (git version). When rule keywords conflict, Surciata will restart itself endless. I attacked two rules for your reference :

Conflict :
alert tcp any any -> any any (msg:"LOCAL HTTP Outgoing Private Key"; filemagic:"RSA private key"; filestore; app-layer-protocol:http; sid:1000017; rev:1;)

Not conflict :
alert http any any -> any any (msg:"LOCAL HTTP Outgoing Private Key"; filemagic:"RSA private key"; filestore; sid:1000017; rev:1;)

Files

core.txt (2.02 KB) core.txt Peter Manev, 10/25/2015 04:37 AM
Actions
Copy link
 #1

Updated by Peter Manev about 9 years ago

I could not reproduce the case - however - I can consistently reproduce the following with beta4 and latest git (2.1dev - 86711a1) -
Only rule used:

alert tcp any any -> any any (msg:"LOCAL HTTP Outgoing Private Key"; filemagic:"RSA private key"; filestore; app-layer-protocol:http; sid:1000017; rev:1;)

and a starting line:
suricata -c /etc/suricata/suricata.yaml -S tmp/test1.rules  -v --af-packet

(the runmode does not matter actually)
after stopping suricata (Ctrl+C) it segfaults - see attached.

If beta4 is started as a daemon (no -S above) - we get the following:

25/10/2015 -- 09:41:48 - <Info> - IP reputation disabled
25/10/2015 -- 09:41:48 - <Error> - [ERRCODE: SC_ERR_CONFLICTING_RULE_KEYWORDS(141)] - rule contains conflicting keywords.
*** Error in `/usr/bin/suricata': double free or corruption (fasttop): 0x0000000003312c60 ***
Aborted (core dumped)

Actions
Copy link
 #2

Updated by Victor Julien about 9 years ago

  • Assignee set to OISF Dev
  • Target version set to 3.0RC1

Looks like 2 bugs actually. Main one is the memory corruption. But the rule is valid but is considered to be invalid, so that's the 2nd bug. Fixing the 2nd part will hide the 1st, so it's important to fix the cause of the mem corruption first.

Actions
Copy link
 #3

Updated by Alexander Gozman about 9 years ago

Victor Julien wrote:

Looks like 2 bugs actually. Main one is the memory corruption. But the rule is valid but is considered to be invalid, so that's the 2nd bug. Fixing the 2nd part will hide the 1st, so it's important to fix the cause of the mem corruption first.

Looks strange, but placing "filemagic:"RSA private key"; filestore;" after "app-layer-protocol:http;" makes rule loader happy.

Actions
Copy link
 #4

Updated by Victor Julien almost 9 years ago

  • Target version changed from 3.0RC1 to 70
Actions
Copy link
 #5

Updated by Victor Julien almost 9 years ago

  • Priority changed from Normal to High
Actions
Copy link
 #6

Updated by Andreas Herz almost 9 years ago

I can't reproduce the segfault Peter reports, does anyone else get this segfault?

Actions
Copy link
 #7

Updated by Peter Manev almost 9 years ago

I just rerun the test (that I have previously described in this thread) -

suricata -c /etc/suricata/suricata.yaml -S test1.rules  -v --af-packet
[4808] 1/2/2016 -- 11:24:17 - (suricata.c:1073) <Notice> (SCPrintVersion) -- This is Suricata version 3.0dev (rev 44a444b)
...
...
[4808] 1/2/2016 -- 11:24:17 - (ippair.c:211) <Info> (IPPairInitConfig) -- allocated 262144 bytes of memory for the ippair hash... 4096 buckets of size 64
[4808] 1/2/2016 -- 11:24:17 - (ippair.c:234) <Info> (IPPairInitConfig) -- preallocated 1000 ippairs of size 136
[4808] 1/2/2016 -- 11:24:17 - (ippair.c:236) <Info> (IPPairInitConfig) -- ippair memory usage: 398144 bytes, maximum: 16777216
[4808] 1/2/2016 -- 11:24:17 - (util-magic.c:62) <Info> (MagicInit) -- using magic-file /usr/share/file/magic
[4808] 1/2/2016 -- 11:24:17 - (suricata.c:1950) <Info> (SetupDelayedDetect) -- Delayed detect disabled
[4808] 1/2/2016 -- 11:24:17 - (reputation.c:620) <Info> (SRepInit) -- IP reputation disabled
[4808] 1/2/2016 -- 11:24:17 - (detect.c:416) <Info> (ProcessSigFiles) -- Loading rule file: test1.rules
[4808] 1/2/2016 -- 11:24:17 - (detect-filemagic.c:396) <Error> (DetectFilemagicSetup) -- [ERRCODE: SC_ERR_CONFLICTING_RULE_KEYWORDS(141)] - rule contains conflicting keywords.
Segmentation fault
Actions
Copy link
 #8

Updated by Victor Julien over 8 years ago

  • Status changed from New to Assigned
  • Assignee changed from OISF Dev to Andreas Herz
Actions
Copy link
 #9

Updated by Andreas Herz over 8 years ago

Within gdb run and the segfault I did narrow it down to the point, that sm->type is set to 192 (I had another run with sm->type=224 when I looked into this bug the first time) which makes no sense since the size of the array is just 114.
But I couldn't find the line where this error occurs, maybe some strange overwrite somewhere else as well.

When I set the breakpoint in detect-filemagic.c in the line with "sm->type = DETECT_FILEMAGIC" it's set to 100 which is correct. I tried to do a "watch sm->type" within gdb but that took several hours and ended up with some other errors that completely spammed my backlog :)

So before I waste too much time does anyone have an idea where the wrong sm->type = X might happen?

Actions
Copy link
 #10

Updated by Andreas Herz over 8 years ago

  • Status changed from Assigned to Closed
  • Target version changed from 70 to 3.1rc1
Actions
Copy link

Also available in: Atom PDF