[Snort-sigs] FPs on community sids 100000118,100000119

Jeff Kell jeff-kell at ...922...
Mon Jan 9 17:01:01 EST 2006


The original rules are designed to catch a buffer overflow with an 
overly long 'Content-type:' or 'Content-encoding:' tag.  The current 
signatures are looking for those content strings, followed by 200 bytes 
of  [^\r\n].  Several webmail clients are causing FPs on this sig, the 
text they actually return is delimited by <br> notation, or with AOL 
they are sometimes delimited by the literals "\r\n" (format string?).  
At any rate, the expected <cr>/<lf> terminators aren't there, and the 
sigs fire.

The following changes revise the signatures to look for the leading 
HTTP/ response from the server (the FPs I have seen all appear in 
continuation packets, not the initial response):

> alert tcp $EXTERNAL_NET 80 -> $HOME_NET any (msg:"COMMUNITY WEB-CLIENT 
> Internet Explorer URLMON.DLL Content-Type Overflow Attempt"; 
> flow:to_client,established; content:"HTTP/"; offset:0; depth:5; 
> content:"Content-Type|3A|"; nocase; 
> pcre:"/Content-Type\x3A[^\r\n]{300,}/i"; classtype:attempted-admin; 
> reference:bugtraq,7419; reference:cve,2003-0113; 
> reference:url,www.microsoft.com/technet/security/bulletin/MS03-015.mspx; 
> sid:100000118; rev:2;)

> alert tcp $EXTERNAL_NET 80 -> $HOME_NET any (msg:"COMMUNITY WEB-CLIENT 
> Internet Explorer URLMON.DLL Content-Encoding Overflow Attempt"; 
> flow:to_client,established; content:"HTTP/"; offset:0; depth:5; 
> content:"Content-Encoding|3A|"; nocase; 
> pcre:"/Content-Encoding\x3A[^\r\n]{300,}/i"; 
> classtype:attempted-admin; reference:bugtraq,7419; 
> reference:cve,2003-0113; 
> reference:url,www.microsoft.com/technet/security/bulletin/MS03-015.mspx; 
> sid:100000119; rev:2;)

Jeff




More information about the Snort-sigs mailing list