Bug #1
closedwithin doesn't respect distance while carrying out a match
Description
A signature containing content:"abc"; distance:1; within:3; can never match. The signature parser needs to detect this, print a error message and invalidate the signature.
^ Changing the problem statement to what Will has specified\
This actually valid. In snort distance moves where to begin searching for the match. So lets look at the following rule.
alert tcp any any -> any any (msg:"AllWorkAndNoPlay"; content:"AllWorkAndNoPlayMakesWill"; content:"DullBoy"; distance:1; within:7; sid:2;)
and the string
AllWorkAndNoPlayMakesWillADullBoy
In snort this will match as we simply move where to start looking for the within match here we move 1 byte past the end of the previous match skipping over the "A". Since "DullBoy" is seven bytes this rule alerts.
01/04-11:29:26.927934 [**] [1:2:0] AllWorkAndNoPlay [**] [Priority: 0] {TCP} 192.168.2.3:39867 -> 209.85.225.105:80
01/04-11:29:26.981495 [**] [1:2:0] AllWorkAndNoPlay [**] [Priority: 0] {TCP} 209.85.225.105:80 -> 192.168.2.3:39867
Files
Updated by Victor Julien almost 15 years ago
- Project changed from 1 to Suricata
- Target version deleted (
1)
Updated by Victor Julien almost 15 years ago
- Due date set to 11/30/2009
- Assignee set to OISF Dev
- Target version set to 0.8.0
Updated by Victor Julien almost 15 years ago
- Estimated time changed from 0.50 h to 2.00 h
Updated by Anoop Saldanha almost 15 years ago
- Assignee changed from OISF Dev to Anoop Saldanha
Updated by Victor Julien over 14 years ago
- Target version changed from 0.8.0 to 0.8.1
Updated by Anoop Saldanha over 14 years ago
- File 0001-Fix-for-bug-1.-Fixes-the-conflict-between-distance.patch 0001-Fix-for-bug-1.-Fixes-the-conflict-between-distance.patch added
Fix attached against b28488508b9c91ebb1e77174b1e0e0533391d588
Updated by Will Metcalf over 14 years ago
- File allworkandnoplayplain.pcap allworkandnoplayplain.pcap added
- Estimated time changed from 2.00 h to 3.00 h
This actually valid. In snort distance moves where to begin searching for the match. So lets look at the following rule.
alert tcp any any -> any any (msg:"AllWorkAndNoPlay"; content:"AllWorkAndNoPlayMakesWill"; content:"DullBoy"; distance:1; within:7; sid:2;)
and the string
AllWorkAndNoPlayMakesWillADullBoy
In snort this will match as we simply move where to start looking for the within match here we move 1 byte past the end of the previous match skipping over the "A". Since "DullBoy" is seven bytes this rule alerts.
01/04-11:29:26.927934 [**] [1:2:0] AllWorkAndNoPlay [**] [Priority: 0] {TCP} 192.168.2.3:39867 -> 209.85.225.105:80
01/04-11:29:26.981495 [**] [1:2:0] AllWorkAndNoPlay [**] [Priority: 0] {TCP} 209.85.225.105:80 -> 192.168.2.3:39867
Updated by Anoop Saldanha over 14 years ago
- Subject changed from within and distance content modifiers can conflict to within doesn't respect distance while carrying out a match
Updated by Victor Julien over 14 years ago
- Target version changed from 0.8.1 to 0.8.2
- Estimated time changed from 3.00 h to 4.50 h
Updated by Anoop Saldanha over 14 years ago
- File 0001-Fix-for-bug-1.-Update-distance-within-keyword-to-be.patch 0001-Fix-for-bug-1.-Update-distance-within-keyword-to-be.patch added
Attached a patch
Updated by Victor Julien over 14 years ago
Is this issue still valid? Anoop's patch fixes it in our old code, but that code changed significantly.
Updated by Anoop Saldanha over 14 years ago
Victor Julien wrote:
Is this issue still valid? Anoop's patch fixes it in our old code, but that code changed significantly.
Let me recheck this thing with the new code.
Updated by Victor Julien over 14 years ago
- Status changed from New to Closed
- % Done changed from 0 to 100
I believe this is no longer an issue. If it still is, please reopen the bug.