[Snort-sigs] SID 1221 - musicat empower access
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 :)
> 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.
>> 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.
>>> 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
>>>> Just some thoughts. As for me, I'm suppressing it since I don't run it
>>>> and this rule is old like bottom posting.
>>>> 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
>>>> Join now and get one step closer to millions of Verizon customers
>>>> Snort-sigs mailing list
>>>> Snort-sigs at lists.sourceforge.net
-------------- next part --------------
An HTML attachment was scrubbed...
More information about the Snort-sigs