<div>Hey Guise,</div><div><br></div>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.<div>
<br></div><div>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.</div>
<div><br></div><div>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.</div><div><br></div>
<div>Matt<br><div><br><div class="gmail_quote">On Tue, Dec 22, 2009 at 10:01 AM, Guise McAllaster <span dir="ltr"><<a href="mailto:guise.mcallaster@...2420..." target="_blank">guise.mcallaster@...2420...</a>></span> wrote:<br>

<blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">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="<br>


<br>Just some thoughts.  As for me, I'm suppressing it since I don't run it and this rule is old like bottom posting.<br><br>Cheers,<br><font color="#888888"><br>Guise<br>
</font><br>------------------------------------------------------------------------------<br>
This SF.Net email is sponsored by the Verizon Developer Community<br>
Take advantage of Verizon's best-in-class app development support<br>
A streamlined, 14 day to market process makes app distribution fast and easy<br>
Join now and get one step closer to millions of Verizon customers<br>
<a href="http://p.sf.net/sfu/verizon-dev2dev" target="_blank">http://p.sf.net/sfu/verizon-dev2dev</a> <br>_______________________________________________<br>
Snort-sigs mailing list<br>
<a href="mailto:Snort-sigs@lists.sourceforge.net" target="_blank">Snort-sigs@lists.sourceforge.net</a><br>
<a href="https://lists.sourceforge.net/lists/listinfo/snort-sigs" target="_blank">https://lists.sourceforge.net/lists/listinfo/snort-sigs</a><br>
<br></blockquote></div><br>
</div></div>