Re: Using within after http_headers

[Alex Kirk <akirk () sourcefire com>]

Actually, the use of distance:0 in a uricontent is almost certainly no good,
as you've mentioned - if for no other reason than the possible false
positive cases. I'll review the spyware rules for cases where that occurs,
and fix them up. If there are other places you've seen that, let me know, so
we can take care of them.

On Fri, Apr 30, 2010 at 3:44 PM, Will Metcalf <william.metcalf () gmail com>wrote:

> > On Fri, Apr 30, 2010 at 2:31 PM, Joel Esler <jesler () sourcefire com>
> wrote:
> > http_client_body and http_uri aren't normalizers though, they are just
> > pointers to locations, the way that I read it.
> http_uri is normalized... Not sure about http_client_body..
>
> > As far as the distance:0; that's simply saying that the subsequent
> content
> > must be after the uricontent.  not any distance "away" from the end of
> it,
> > just after the previous match succeeded.
>
> I understand but this can lead to false negatives. If the uricontent
> has to be decoded, using the uricontent,content,distance:0 combo
> causes the rule not to fire completely....
>
> Regards,
>
> Will
>
> > J
> > On Fri, Apr 30, 2010 at 3:21 PM, Will Metcalf <william.metcalf () gmail com
> >
> > wrote:
> > > > Correct.  Since this is a normalized field (similar to uricontent),
> you
> > > > can't have a relative statement to a normalized http field like that.
> > > > This is as designed.
> > > This is not entirely accurate ;-)...  For example some of the
> > > spyware-put rules mix uricontent,content and distance:0
> > >
> > > Also from my tests you can mix http_client_body and http_uri with
> > > distance and within, but it fails always for cookie and header.  Also
> > > with http_uri just like uricontent if you encode the url distance and
> > > within doesn't work.
> > >
> > > Regards,
> > >
> > > Will
> > >
> > > On Fri, Apr 30, 2010 at 11:47 AM, Joel Esler <jesler () sourcefire com>
> > > wrote:
> > >
> > > > On Fri, Apr 30, 2010 at 12:35 PM, Mike Cox <mike.cox52 () gmail com>
> wrote:
> > > > > I'm testing some rules and it seems that using the within content
> > > > > modifier on a content match that is relative to a previous content
> > > > > match and uses the http_headers content modifier does not work.  For
> > > > > example, this is the original rule that is not alerting:
> > > > >
> > > > > alert tcp any any -> $HOME_NET $HTTP_PORTS (msg:"Testing Referer";
> > > > > flow:established,to_server; content:"|0d 0a|Referer\: "; nocase;
> > > > > http_header; content:!"google.com"; nocase; within:50;
> > > > > classtype:bad-unknown; rev:1; sid:7500010;)
> > > > >
> > > > > But if I remove the within OR the http_header content modifiers, the
> > > > > rule alerts.  So both these alert:
> > > > >
> > > > > alert tcp any any -> $HOME_NET $HTTP_PORTS (msg:"Testing Referer";
> > > > > flow:established,to_server; content:"|0d 0a|Referer\: "; nocase;
> > > > > content:!"google.com"; nocase; within:50; classtype:bad-unknown;
> > > > > rev:1; sid:7500010;)
> > > > >
> > > > > alert tcp any any -> $HOME_NET $HTTP_PORTS (msg:"Testing Referer";
> > > > > flow:established,to_server; content:"|0d 0a|Referer\: "; nocase;
> > > > > http_header; content:!"google.com"; nocase; classtype:bad-unknown;
> > > > > rev:1; sid:7500010;)
> > > > >
> > > > > Is there some weird stuff going on with the HTTP header buffer such
> > > > > that subsequent within content modifiers don't work?  If so, is this
> > > > > as designed?
> > > > >
> > > > > Thanks.
> > > > >
> > > > > -Mike Cox
> ------------------------------------------------------------------------------
> > > > > _______________________________________________
> > > > > Snort-sigs mailing list
> > > > > Snort-sigs () lists sourceforge net
> > > > > https://lists.sourceforge.net/lists/listinfo/snort-sigs
> ------------------------------------------------------------------------------
> > > > _______________________________________________
> > > > Snort-sigs mailing list
> > > > Snort-sigs () lists sourceforge net
> > > > https://lists.sourceforge.net/lists/listinfo/snort-sigs
>
>
> ------------------------------------------------------------------------------
> _______________________________________________
> Snort-sigs mailing list
> Snort-sigs () lists sourceforge net
> https://lists.sourceforge.net/lists/listinfo/snort-sigs



-- 
Alex Kirk
AEGIS Program Lead
Sourcefire Vulnerability Research Team
+1-410-423-1937
alex.kirk () sourcefire com

------------------------------------------------------------------------------

_______________________________________________
Snort-sigs mailing list
Snort-sigs () lists sourceforge net
https://lists.sourceforge.net/lists/listinfo/snort-sigs