newsfeed at ...1411...
Fri Jun 6 13:30:05 EDT 2003
This rule has been brought up a couple of times before, and is once
again causing a partular of false positives. Seeing and reading a bit
about this (some discussions were up in March and then back in September
on the snort-users list) and reading the BugTraq listing of this
particular exploit, wouldn't it make sense instead of just triggering on
case of media player rules) write a conjoining test for the client type
(namely, Mozilla and Netscape). We've gotten a number of false positives
coming from Lycos and thier evil-stepchildren's web pages, but since
we're almost exlcusively IE at work, this would definitely say this is a
brisk amount of bad triggers. I wrote a rule a while back for the
Quicktime client buffer overflow (I don't think it made it in to the
ruleset, just go back a few months inthe archive and look for Quicktime
in the subject header) where I test for the client and version via a
content rule, and then trigger the alert when it matches the
length/size. I think a similar approach can be used to kill off a number
of false positives on this particular rule.
Anybody wanna take a stab?
alert tcp $EXTERNAL_NET $HTTP_PORTS -> $HOME_NET any (msg:"WEB-CLIENT
reference:bugtraq,5293; sid:1841; rev:3;)
my quicktime rule as an example:
alert tcp $HOME_NET any -> any any (msg:"LOCAL INSIDE QuickTime Player
Buffer Overflow Attempt"; content: "User-Agent\: QuickTime"; nocase;
content: !"(qtver=6.1"; nocase; content: "os=Windows"; nocase;
flow:from_client,established; dsize: >400;classtype:attempted-admin;)
If there is a way to catch the User-Agent stuff for client based sigs
(similar to SID 311), it'd also help with narrowing down issues with
those types of exploits and bugs.
More information about the Snort-sigs