[Oisf-users] distance, uricontent

[Will Metcalf]

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
>