[Oisf-users] Issue with negated isdataat?

[Jason Williams]

Perhaps this may have to do with
https://redmine.openinfosecfoundation.org/issues/1412

Maybe someone can chime in here to validate this issue with the buffer
order inspection issue?

On Thu, Apr 20, 2017 at 1:35 PM, Harley H <bobb.harley at gmail.com> wrote:

> With that settled I'm running into another issue.
>
> Take these rules for example:
> #rules
>
> alert tcp any any -> any any (msg:"It's Alive!!! 1";
> byte_extract:1,0,size; content:"123"; isdataat:!size; sid:1102014; rev:1;)
> alert tcp any any -> any any (msg:"It's Alive!!! 2";
> byte_extract:1,0,size; content:"123"; isdataat:size; sid:1102015; rev:1;)
> alert tcp any any -> any any (msg:"It's Alive!!! 3";
> byte_extract:1,0,size; content:"123"; isdataat:!size,relative; sid:1102016;
> rev:1;)
> alert tcp any any -> any any (msg:"It's Alive!!! 4";
> byte_extract:1,0,size; content:"123"; isdataat:size,relative; sid:1102017;
> rev:1;)
> alert tcp any any -> any any (msg:"It's Alive!!! 5"; content:"123";
> isdataat:!8; sid:1102018; rev:1;)
> alert tcp any any -> any any (msg:"It's Alive!!! 6"; content:"123";
> isdataat:8; sid:1102019; rev:1;)
> alert tcp any any -> any any (msg:"It's Alive!!! 7"; content:"123";
> isdataat:!8,relative; sid:1102020; rev:1;)
> alert tcp any any -> any any (msg:"It's Alive!!! 8"; content:"123";
> isdataat:8,relative; sid:1102021; rev:1;)
>
> In Snort, the following hit:
> 1102014
> 1102016
> 1102018
> 1102020
>
> In Suricata:
> 1102015
> 1102017
> 1102018
> 1102020
>
> Is this an expected discrepancy? Seems like it has something to do with
> the byte_extract.
>
>
> The packet data is:
> "\x0812334567"
>
> PCAP: https://packettotal.com/cgi-bin/view-analysis.cgi?id=
> dafb74032ed3c43806d5eea0a1e7d6c0
>
> -Harley
>
> On Thu, Apr 20, 2017 at 12:48 PM, Jason Williams <
> jwilliams at emergingthreats.net> wrote:
>
>> I ran your rules on my test rig and received the expected results:
>>
>> I believe it's the spaces in your "isdataat" portion causing the rules to
>> fire unexpectedly in suricata. We (ET) never separate fields with spaces
>> such as in the rules provided.
>>
>> #rules
>>
>> 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;)
>>
>> #results
>>
>> 02/23/2017-15:48:51.024811  [**] [1:1102010:1] It's Alive!!! [**]
>> [Classification: (null)] [Priority: 3] {TCP} 10.211.55.3:49800 ->
>> 10.211.55.2:80
>> 02/23/2017-15:48:51.024811  [**] [1:1102013:1] It's Alive!!! [**]
>> [Classification: (null)] [Priority: 3] {TCP} 10.211.55.3:49800 ->
>> 10.211.55.2:80
>>
>> Thanks,
>>
>> Jason
>>
>> On Thu, Apr 20, 2017 at 10:25 AM, Harley H <bobb.harley at gmail.com> wrote:
>>
>>> 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.
>>>
>>> PCAP: https://packettotal.com/cgi-bin/view-analysis.cgi?id=4
>>> 38c8f1a3041b5908a20bf3e7e8e3063
>>>
>>> Has anyone else noticed this or am I misunderstanding something?
>>>
>>> -Harley
>>>
>>> _______________________________________________
>>> Suricata IDS Users mailing list: oisf-users at openinfosecfoundation.org
>>> Site: http://suricata-ids.org | Support: http://suricata-ids.org/suppor
>>> t/
>>> List: https://lists.openinfosecfoundation.org/mailman/listinfo/ois
>>> f-users
>>>
>>>
>>
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.openinfosecfoundation.org/pipermail/oisf-users/attachments/20170420/131f9f11/attachment-0002.html>