Re: SID 1221 - musicat empower access

[Matt Olney <molney () sourcefire com>]

OK...after some testing I updated the rule and changed the message.  Should
be out next week, unless we have an emergency push sooner.

Thanks again for the info, Guise.

Matt

On Tue, Dec 22, 2009 at 10:21 AM, Matt Olney <molney () sourcefire com> wrote:

> Hey Guise,
>
> Thanks for the heads up.  I don't have any records of prior false positive
> reports, but the PoCs that I have available seem to indicate that your
> change would probably be an improvement on things.  I'll whip up a PCAP and
> see what I can do.
>
> Now, as for your attitude.  Seriously, Guise:  "Seems a little simple, even
> for VRT.", really?  That's weak sauce.  Don't come in here trotting out an 8
> year old rule and bashing the VRT.  You have problems with us, let's hear
> it.  Here or privately, I don't care.  I had thought that we had moved
> beyond this.  We certainly are not perfect, and as I've said before I always
> welcome the opportunity to improve our ruleset.  I feel that we've been very
> responsive to the concerns on this list, that we've reached out to the
> emerging threats group and that you and I specifically had come to an
> understanding that we would work together on a more reasonable level.  Feel
> free to call us on our crap, its one of the great benefits of having an
> easily accessible, open set of rules (with some set of contractually
> obligated obfuscation).  But when you do this way, as opposed to something
> more constructive, it makes you look small and a schmuck.
>
> I'm really trying here, and I think there is a lot coming up that will be
> of use to the open source rule writers.  Let's try and work together for the
> benefit of Snort users.
>
> Matt
>
> On Tue, Dec 22, 2009 at 10:01 AM, Guise McAllaster <
> guise.mcallaster () gmail com> wrote:
>
> > Please let me bring our attention to SID 1221 - musicat empower access.
> > This detects attempted access that results in a path disclosure.  It is also
> > from 2001.  A few things to note.  From what I can tell, it is not "musicat"
> > but "muscat".  Next, the rule only looks for uricontent:"empower".    Seems
> > a little simple, even for VRT.  What about doing a little more to reduce the
> > false positive?  How about uricontent:"empower?"  or
> > uricontent:"empower?DB="
> >
> > Just some thoughts.  As for me, I'm suppressing it since I don't run it
> > and this rule is old like bottom posting.
> >
> > Cheers,
> >
> > 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