Bug #1584
closed
Rule keywords conflict will cause Suricata restart itself in loop
Added by Samiux A over 8 years ago.
Updated almost 8 years ago.
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
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)
- 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.
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.
- Target version changed from 3.0RC1 to 70
- Priority changed from Normal to High
I can't reproduce the segfault Peter reports, does anyone else get this segfault?
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
- Status changed from New to Assigned
- Assignee changed from OISF Dev to Andreas Herz
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?
- Status changed from Assigned to Closed
- Target version changed from 70 to 3.1rc1
Also available in: Atom
PDF