[Oisf-users] distance, uricontent

[Will Metcalf]

> Re: 3.  Ignoring the modifiers could change the behaviour of existing
> signatures.

Essentially this is what happens in snort now, if you are using a
uricontent1:/foo; uricontent2:bar; distance:0; cocktail to match on
/foobar

1. match uricontent1:/foo from the beginning of the normalized buffer
2. match uricontent2:bar from the beginning of the normalized buffer
even though distance:0 is set because it always starts from the
beginning of the normalized buffer.

You could set uricontent1:/foo; uricontent2:bar; distance:4; and the
sig would still match.  Or are you trying to say support distance but
do as snort does and treat it like depth starting from beginning of
the normalized buffer?

Regards,

Will

On Thu, Mar 18, 2010 at 11:46 AM, Geoff Whittington
<geoff.whittington at gmail.com> wrote:
> Re: 1. Since snort currently does not fail the signature, then
> rejecting the rule could create headaches for users.
>
> Re: 2.  I would agree - accept the rule and use the modifiers with the
> normalized buffer.
>

>
> I don't really like this idea but: create a configuration switch that
> spells out the behaviour of the distance/within modifier to support
> older signatures.
>
> On Thu, Mar 18, 2010 at 11:20 AM, Will Metcalf
> <william.metcalf at gmail.com> wrote:
>> IMHO the implementation in snort is broken. From what I have seen
>> distance always starts at the beginning of the normalized buffer
>> rather than from the end of the last uricontent match.  I don't think
>> this is right....
>>
>> We should do one of the following...
>>
>> 1. Reject the rule because in snort it really doesn't work.
>> 2. Accept the rule and setup distance and within to work against the
>> normalized buffer(my vote).
>> 3. Accept the rule and ignore distance as in snort it really doesn't work.
>>
>> Things get weirder when you start to mix and match uricontent,content
>> and within/distance. but we will save that for later.
>>
>> What does the community think?
>>
>> Regards,
>>
>> Will
>>
>> #test 32 uricontent with distance modifier
>> #This is broken the sig still fires using two uricontent matches
>> distance always starts at the beginning of normalized buffer
>> #
>> #file allworkandnoplayplain.pcap and allworkandnoplayencoded.pcap
>> #alert tcp any any -> any any (msg:"uricontent match against
>> /AllWorkAndNoPlayMakesWillADullBoy with distance";
>> uricontent:"/AllWorkAndNoPlay"; uricontent:"MakesWillADullBoy";
>> distance:17; classtype:bad-unknown; sid:32; rev:1;)
>>
>> On Thu, Mar 18, 2010 at 9:52 AM, Geoff Whittington
>> <geoff.whittington at gmail.com> wrote:
>>> Hello,
>>>
>>> Can someone confirm whether there was a decision about the
>>> interpretation of uricontent as a "pattern match"? i.e.
>>>
>>> uricontent:"BAAD"; uricontent:"FOOD"; distance:0;
>>>
>>> According to snort:
>>>
>>> "The distance keyword allows the rule writer to specify how far into a
>>> packet Snort should
>>> ignore before starting to search for the specified pattern relative to
>>> the end of the previous
>>> pattern match."
>>>
>>> Cheers,
>>>  - Geoff
>>> _______________________________________________
>>> Oisf-users mailing list
>>> Oisf-users at openinfosecfoundation.org
>>> http://lists.openinfosecfoundation.org/mailman/listinfo/oisf-users
>>>
>> _______________________________________________
>> Oisf-users mailing list
>> Oisf-users at openinfosecfoundation.org
>> http://lists.openinfosecfoundation.org/mailman/listinfo/oisf-users
>>
>