Bug #149
closed
FN on suricata with i(cmp)type:9
Added by rmkml rmkml over 14 years ago.
Updated over 14 years ago.
Description
Hi,
I have a FN with this (old) signature and joigned pcap:
alert icmp $EXTERNAL_NET any -> $HOME_NET any (msg:"ICMP IRDP router advertisement"; itype:9; reference:arachnids,173; reference:bugtraq,578; reference:cve,1999-0875; classtype:misc-activity; sid:363; rev:7;)
Tested on suricata v0.8.2 and yesterday git.
Regards
Rmkml
Files
- Status changed from New to Assigned
- Assignee set to Victor Julien
- Target version set to 0.9.0
Issue confirmed, looking into it.
- Status changed from Assigned to Feedback
It seems to me it's not a FN after all. The signature uses $HOME_NET as destination, and the packet has 255.255.255.255 as dst address. This would not be a part of $HOME_NET, right? Or should it be as 255.255.255.255 is a broadcast address?
Thx you again Victor for your very good jobs and support!
My description pb is wrong, This signature not firing with another signature.
Please test with theses two signatures on pcap:
alert icmp any any -> any any (msg:"ICMP IRDP router advertisement"; itype:9; classtype:misc-activity; sid:363; rev:7;)
alert ip 200.31.33.70 31337 -> any any (msg:"test1"; content:"|05|"; sid:90003123; rev:1; )
with theses two signatures, no alert firing. If you comment/disable second sig: first sig firing.
Regards
Rmkml
- Target version changed from 0.9.0 to 0.9.1
I've been unable to reproduce this issue. Sigs + pcap work fine here. Will continue to investigate the issue.
I have verified this bug on the test rig. The behavior seems to be the same across all operating systems and compiler optimization levels. With both rules enabled we don't get an alert. If we disable the second rule the first rule fires.
alert icmp any any -> any any (msg:"ICMP IRDP router advertisement"; itype:9; classtype:misc-activity; sid:363; rev:7;)
alert ip 200.31.33.70 31337 -> any any (msg:"test1"; content:"|05|"; sid:90003123; rev:1; )
I wonder why I can't reproduce the issue. Can you describe the exact steps Will?
Yesterday I looked at the bug briefly and seems that we are loosing somehow the sgh (with both sigs enabled).
531 det_ctx->sgh = SigMatchSignaturesGetSgh(th_v, de_ctx, det_ctx, p);
(gdb)
534 if (det_ctx->sgh == NULL) {
(gdb)
535 SCLogDebug("no sgh for this packet, nothing to match against");
With just the first sig it get's an sgh. Any idea of recent changes related to sgh grouping? The "pass" action implementation didn't change that part of the code at all. Also, commenting the ordering functions call doesn't fix the issue.
- Status changed from Feedback to Closed
- % Done changed from 0 to 100
Fixed in current git master.
Also available in: Atom
PDF