[Snort-users] Possible Memory Overlap/Bug? Help!

Lawrence Reed Lawrence.Reed at ...1444...
Thu Dec 12 06:40:04 EST 2002

Hash: SHA1

I believe this to be a known bug in the stream4 reassembler.  I have had
some discussions with the snort developers  about a similiar problem.
~ The discussion was taken offline after a while,, but never resolved.
~ In my case the problem involved packet loss.  I verified in the code
that the stream reassembly buffer is not cleared after each use ( for
performance reasons ) so when a stream misses a packet that space in the
buffer contains the previous streams contents.  When this buffer is
passed to the rules engine an alert is generated relating to the old
data.  I am currently trying to resolve this issue.  I will post a patch
to snort-devel when it is ready.

related discussion:

Kevin Peuhkurinen wrote:

| I hope somebody can help me with this as I am nearing my wits end.  
| I'm having a problem with anomalous "P2P GNUTELLA GET" alerts which
| appear to be caused by some kind of packet overlap or something.
| I had been having these problems with Snort 1.8.7, so upgraded to
| 1.9.0 and am still encountering them.    The sensor reporting them is
| running Mandrake 8.1 with the latest stable release of libpcap.
| According to this sensor, the packets in question are originating from
| my SMTP server, with the destination being other SMTP servers on port
| 25.    When I look at the packet in ACID, sure enough there is what
| appears to be HTTP GET requests.   This was enough to make me
| curious.   What I eventually decided to do was use a different machine
| to capture all of the traffic on port 25 to try to figure out what was
| going on.
| The thing is, the packets that are being logged by the sensor do not
| match the packets that are being captured by the other machine.
| Here is an example:
| From the sensor:
| Src:  My SMTP Server    Dest: Remote SMTP Server
| Src Port: 4479, Dest Port: 25
| IP Header Checksum:  0  (Incorrect, should be 0xc88f)
| TCP Header Checksum : 0  (Incorrect, should be 0x5b62)
| TCP Flags: ACK/PSH
| TCP Seq:  509426611
| TCP Ack: 2900267714
| The data contains an HTTP GET request followed by a bunch of garbage.
| When I look at the captured packets from the other machine, there is
| no such packet.   The stream itself is an outgoing email with a fairly
| long attachment.   There is one packet with matching Seq & Ack #'s,
| but it is actually just an ACK from the remote SMTP server back to my
| server.   Certainly nowhere in any of the packets is anything that
| looks remotely like the HTTP GET which Snort is reporting on.
| However, I do know that at the same time, a user was making that HTTP
| connection since I can see traffic to the host in my firewall logs.
| Therefore, I have to conclude that somehow snort is getting its
| traffic mixed up.    This is the only alert I have seen that looks
| like it is happening to.   All other alerts appear to be genuine.
| Any thoughts?
| Thanks!
| -------------------------------------------------------
| This sf.net email is sponsored by:
| With Great Power, Comes Great Responsibility Learn to use your power
| at OSDN's High Performance Computing Channel
| http://hpc.devchannel.org/
| _______________________________________________
| Snort-users mailing list
| Snort-users at 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

- --
Larry Reed  Lawrence.Reed at ...1444...
NOAA IT Security Office
PGP Public Key:

Version: GnuPG v1.0.6 (GNU/Linux)
Comment: Using GnuPG with Netscape - http://enigmail.mozdev.org


More information about the Snort-users mailing list