[Emerging-Sigs] Signature for Microsoft Internet Explorer MSHTML Findtext Processing Issue
jesler at sourcefire.com
Thu Oct 28 07:39:20 EDT 2010
Actually in Snort, the first content match doesn't need offset:0;. However, if the author is trying to keep everything after the initial content match relative to the previous content match, then distance:0; on the subsequent content matches is correct.
I have not looked at this vulnerability, but is there no way that this can be combined or constricted in some way? Perhaps with http_ modifiers?
On Oct 28, 2010, at 6:28 AM, rmkml wrote:
> Hi Dave,
> thx for this sig,
> maybe I have a small comment: for first content, please change distance:0 to offset:0.
> two work, but distance:0 on first place not work on suricata, if I remember correctly.
> On Thu, 28 Oct 2010, dave richards wrote:
>> Hi Matt,
>> Please find the signature for Microsoft Internet Explorer MSHTML Findtext Processing Issue
>> alert tcp $EXTERNAL_NET $HTTP_PORTS -> $HOME_NET any (msg:"ET WEB-ATTACKS Microsoft Internet Explorer MSHTML FindText Processing Issue";
>> flow:to_client,established; content:"type="; nocase; distance:0; content:"textRange."; nocase; distance:0; content:"findText("; nocase; distance:0;
>> classtype:attempted-user; reference:cve,CVE-2010-2553; reference:url,exploit-db.com/exploits/15122;
>> reference:url,exploit-db.com/moaub-27-microsoft-internet-explorer-mshtml-findtext-processing-issue; sid:20101020; rev:1;)
>> Looking forward for your comments if any
> Emerging-sigs mailing list
> Emerging-sigs at emergingthreats.net
> Support Emerging Threats! Get your ET Stuff! Tshirts, Coffee Mugs and Lanyards
More information about the Emerging-sigs