[Snort-sigs] SID 1221 - musicat empower access

Matt Olney molney at ...435...
Tue Dec 22 12:25:49 EST 2009

Well, to be fair, we're pretty light right now (which is awesome for us,
more time for raw research), although you did get queued behind some Adobe
work.  I think we're still doing a pretty good job on fp reports.  For
example, the SA bruteforce from a few weeks ago.

That being said, I do think we may have some room for improvement in this
area.  I'll keep an eye on response times, even if its just "got it and a
bug is in".  If you take time to give us information, you deserve at least


On Tue, Dec 22, 2009 at 12:11 PM, Guise McAllaster <
guise.mcallaster at ...2420...> wrote:

> Thank you for such a prompt response.  Impressive!  This should encourage
> others to submit feedbacks on the rules.  Unless of course said feedbacks
> include pithy jabs at VRT in which case you will get more than just a timely
> fix :)
> Cheers,
> Guise
> On Tue, Dec 22, 2009 at 4:54 PM, Matt Olney <molney at ...435...> wrote:
>> 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 at ...435...>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 at ...2420...> 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 at lists.sourceforge.net
>>>> https://lists.sourceforge.net/lists/listinfo/snort-sigs
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://lists.snort.org/pipermail/snort-sigs/attachments/20091222/437874ee/attachment.html>

More information about the Snort-sigs mailing list