Snort bug with stream reassembly??

[snort () auscert org au]

Hi,

I appear to have discovered what I think might be a snort/preprocessor bug
related to stream reassembly.  In brief, the packet payloads get associated
with the wrong packet headers from what I can tell :( I am using snort
2.0.1 (build 88) on FreeBSD-4.8.

My snort experience is rather limited - I am a snort newbie :) I have tried
google and the snort archives looking for a similar problem but I haven't
found any definite information (though I think there might have been
similar problems in the past).

Background:  I was running snort 2.0.1 looking for P2P traffic.  I got a lot
of false positives from the following rule:

  alert tcp $HOME_NET any -> $EXTERNAL_NET !80 (msg:"P2P GNUTella GET";
  flow:to_server,established; content:"GET "; offset:0; depth:4;
  classtype:policy-violation; sid:1432; rev:4;)

Most of the false positives where listed as coming from one mail server
going to another mail server on dst port 25.  Sounded like email to me.
At first I thought the "GET " was matching the contents of an email message
but this didn't turn out to be the case (I wouldn't be surprised to see "GET "
appear in spam :)

Further investigation (running snort with -d to log the application data)
showed the rule was matching what appeared from the packet payloads to be
HTTP requests.  This didn't make any sense since the alerts that were being
generated were from a well known secure mail server to another well known
secure mail server on dst port 25!

I had captured the traffic using tcpdump so I was able to review it in
it's entirety.  Using tcpdump to read the traffic indicated that snort was
associating the packet payload with the wrong packet headers thereby giving
false alerts.    By viewing the packets with tcpdump I saw that the actual
packet contents associated with the packet header that was being listed by
the alert actually just contained the closing part of an SMTP connection
as I would have normally expected.

However, the payload the rule above matched actually belonged to another
totally unrelated though valid HTTP session.  But somehow it associated
it with packet headers from an SMTP connection??

I don't know enough about the stream4_reassemble preprocessor but if I turn
that off the false alerts also disappear.  Possibly a bug in the reassembly?
Something else?

Thanks for any info or pointers!
Eric


-------------------------------------------------------
This SF.net email is sponsored by Dice.com.
Did you know that Dice has over 25,000 tech jobs available today? From
careers in IT to Engineering to Tech Sales, Dice has tech jobs from the
best hiring companies. http://www.dice.com/index.epl?rel_code=104
_______________________________________________
Snort-users mailing list
Snort-users () lists sourceforge net
Go to this URL to change user options or unsubscribe:
https://lists.sourceforge.net/lists/listinfo/snort-users
Snort-users list archive:
http://www.geocrawler.com/redir-sf.php3?list=snort-users