Re: WEB-CGI phf access - SID 886

[Matt Olney <molney () sourcefire com>]

So, a little bit about how the VRT approaches these older rules:

1)  There is a field in many rules called "metadata".  This field is used by
our product to determine which rules to turn on and off for base rule sets.
 I know that JJ (pulled pork) has been working on integrating a similar set
of functionality into pulled pork.  But here is the important part, if there
is no metadata then we've essentially said don't turn this rule on by
default.

2)  We will also disable rules that we feel are particularly problematic,
either false-positive wise, or performance wise.

3)  We generally only revisit rules when we get information from users that
there is an issue (none reported on this rule), when there is unpdated
functionality in snort that impacts the rule (note that this old rule uses
the newer uricontent) or if we stumble across something in testing.  When we
do this we typically disable, delete or modify the rule, although sometimes
we do simply say the rule is what it is, and we can't change it without
impacting functionality.

In this case I would simply say that you should disable the rule.  I
certainly wouldn't go out and add a pcre check on this, as it isn't worth
the additional overhead.  This would, in general, be part of the tuning
process.

Now, with all of that said...I'm thinking we could probably disable this
rule, I'll throw a bug entry together and make sure I'm not missing
anything.

Matt


On Tue, Dec 29, 2009 at 4:25 PM, Guise McAllaster <
guise.mcallaster () gmail com> wrote:

> Here is another ancient rule that has some false positive:
>
> alert tcp $EXTERNAL_NET any -> $HTTP_SERVERS $HTTP_PORTS (msg:"WEB-CGI phf
> access"; flow:to_server,established; uricontent:"/phf"; nocase;
> metadata:service http; reference:arachnids,128; reference:bugtraq,629;
> reference:cve,1999-0067; classtype:web-application-activity; sid:886;
> rev:12;)
>
> If people still care about this vuln, could we change it to be more
> robust?  I see it false positive on things like 'GET
> /foo/bar/PHFDD_user.js'.
>
> Maybe something like this:
>
> alert tcp $EXTERNAL_NET any -> $HTTP_SERVERS $HTTP_PORTS (msg:"WEB-CGI phf
> access"; flow:to_server,established; uricontent:"/phf"; nocase; nocase;
> pcre:"/\/phf\/?\?/Ui"; metadata:service http; reference:arachnids,128;
> reference:bugtraq,629; reference:cve,1999-0067;
> classtype:web-application-activity; sid:886; rev:13;)
>
> Similar simple file access rules could probably be modified in a similar
> manner (although I have not looked).
>
> If people don't care about the rule, maybe we could prune it out along with
> all exploit specific rules that are over 10 years old.
>
> Thanks.
>
> Guise
>
>
> ------------------------------------------------------------------------------
> This SF.Net email is sponsored by the Verizon Developer Community
> Take advantage of Verizon's best-in-class app development support
> A streamlined, 14 day to market process makes app distribution fast and
> easy
> Join now and get one step closer to millions of Verizon customers
> http://p.sf.net/sfu/verizon-dev2dev
> _______________________________________________
> Snort-sigs mailing list
> Snort-sigs () lists sourceforge net
> https://lists.sourceforge.net/lists/listinfo/snort-sigs
------------------------------------------------------------------------------
This SF.Net email is sponsored by the Verizon Developer Community
Take advantage of Verizon's best-in-class app development support
A streamlined, 14 day to market process makes app distribution fast and easy
Join now and get one step closer to millions of Verizon customers
http://p.sf.net/sfu/verizon-dev2dev

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