[Snort-devel] [Snort-sigs] Re: Signature error?

Andreas Östling andreaso at ...387...
Fri Jan 2 05:58:18 EST 2004


On Mon, Dec 29, 2003 at 09:44:45AM -0600, Ron Shuck wrote:
> Hi,
>  
> I am getting some really weird alerts since upgrading to 2.0.6. I get
> alerts for MS-SQL Worm on packets that are ICMP destination unreachable
> packets. I double checked the event, iphdr and signature tables in the
> database. It is definitely an ICMP packet and the signature was the
> MS-SQL Worm signature.
> 
> Any ideas?

I experienced something similar today on 2.0.6 which I assume is the 
same bug. This is clearly wrong:

01/02-11:28:13.888195  [**] [1:1244:7] WEB-IIS ISAPI .idq attempt [**] 
[Classification: Web Application Attack] [Priority: 1] {UDP} 
192.168.1.6:55680 -> 192.168.4.3:162


Looking at the alerts before that one:

01/02-11:28:05.129902  [**] [1:1419:2] SNMP trap udp [**] 
[Classification: Attempted Information Leak] [Priority: 2] {UDP} 
192.168.1.6:55680 -> 192.168.4.3:162

01/02-11:28:05.921841  [**] [1:1244:7] WEB-IIS ISAPI .idq attempt [**] 
[Classification: Web Application Attack] [Priority: 1] {TCP} 
192.168.3.5:51000 -> 192.168.7.2:80

01/02-11:28:13.888195  [**] [1:1244:7] WEB-IIS ISAPI .idq attempt [**] 
[Classification: Web Application Attack] [Priority: 1] {UDP} 
192.168.1.6:55680 -> 192.168.4.3:162


The actual packet is correct and correctly alerted on, but the info (sid, 
msg, ...) incorrectly remains from the previous alert.
I have a pcap of this so I can reproduce it, and I tried to find the bug 
but ended up lost in fpdetect.c after a while. But when comparing 
fpdetect.c from 2.0.5 with the one in 2.0.6 there are very few changes 
anyway. In 2.0.5 there is:

   if( pLen == 0 )
    {
        if(pmi->iMatchMaxLen == 0)
        {
            pmi->iMatchIndex = pmi->iMatchCount;
        }
    }
    else
    {
        /*
        **  Event Comparison Function
        **  Here the largest content match is the
        **  priority
        */
        if( pmi->iMatchMaxLen < pLen )
        {
            pmi->iMatchMaxLen = pLen;
            pmi->iMatchIndex  = pmi->iMatchCount;
        }
    }


But in 2.0.6 there is:

   if(pLen > 0)
    {
        /*
        **  Event Comparison Function
        **  Here the largest content match is the
        **  priority
        */
        if( pmi->iMatchMaxLen < pLen )
        {
            pmi->iMatchMaxLen = pLen;
            pmi->iMatchIndex  = pmi->iMatchCount;
        }
    }
        

When reverting to old behavior in 2.0.6, the result on the same pcap is 
now correct:

01/02-11:28:05.129902  [**] [1:1419:2] SNMP trap udp [**] 
[Classification: Attempted Information Leak] [Priority: 2] {UDP} 
192.168.1.6:55680 -> 192.168.4.3:162

01/02-11:28:05.921841  [**] [1:1244:7] WEB-IIS ISAPI .idq attempt [**] 
[Classification: Web Application Attack] [Priority: 1] {TCP} 
192.168.3.5:51000 -> 192.168.7.2:80

01/02-11:28:13.888195  [**] [1:1419:2] SNMP trap udp [**] 
[Classification: Attempted Information Leak] [Priority: 2] {UDP} 
192.168.1.6:55680 -> 192.168.4.3:162


The same code exists in 2.1.0 as in 2.0.6, so it may have the bug as 
well. Since I assume the new code was introduced for a reason, simply 
reverting to old one may cause other problems, but but I'll leave that to 
someone who understands what's going on :)
Hopefully this will help a bit.

/Andreas


-------------------------------------------------------
This SF.net email is sponsored by: IBM Linux Tutorials.
Become an expert in LINUX or just sharpen your skills.  Sign up for IBM's
Free Linux Tutorials.  Learn everything from the bash shell to sys admin.
Click now! http://ads.osdn.com/?ad_id=1278&alloc_id=3371&op=click
_______________________________________________
Snort-sigs mailing list
Snort-sigs at lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/snort-sigs




More information about the Snort-devel mailing list