Actions
Bug #2098
closedisdataat: fix parsing issue with leading spaces
Affected Versions:
Effort:
Difficulty:
Label:
Description
Hello,
I'm noticing a potential issue with a negated isdataat check. I'm testing the following four rules against the pcap linked below:
alert tcp any any -> any any (msg: "It's Alive!!!"; content: "Here"; isdataat: !114; sid: 1102010; rev: 1;) alert tcp any any -> any any (msg: "It's Alive!!!"; content: "Here"; isdataat: 114; sid: 1102011; rev: 1;) alert tcp any any -> any any (msg: "It's Alive!!!"; content: "Here"; isdataat: !113; sid: 1102012; rev: 1;) alert tcp any any -> any any (msg: "It's Alive!!!"; content: "Here"; isdataat: 113; sid: 1102013; rev: 1;)
The packet simply contains the following 114 byte string:
"Here is a 114 byte packet to test how a negated isdataat checks works in Suricata. Seems something may be amiss..."
I'd expect rules 1102010 and 1102013 to alert, and that is what happens in Snort. In Suricata, only 1102012 and 1102013 cause an alert. I'm using Suricata 3.2.1.
Files
Updated by Harley H over 7 years ago
Figured out this had to do with the spaces separating 'isdataat' and the values.
Updated by Victor Julien over 7 years ago
- Subject changed from Possible issue with negated isdataat? to isdataat: fix parsing issue with leading spaces
- Assignee set to OISF Dev
- Target version set to 70
Updated by Victor Julien over 7 years ago
- Status changed from New to Assigned
- Assignee changed from OISF Dev to Victor Julien
Updated by Victor Julien over 7 years ago
- Status changed from Assigned to Closed
- Target version changed from 70 to 4.0beta1
Fixed by https://github.com/inliniac/suricata/pull/2683, added a test in https://github.com/inliniac/suricata/pull/2687
This only addresses leading spaces.
Actions