[Snort-devel] Yet more data corruption in stream4/snort-2.0.5

Martin Olsson elof at ...969...
Wed Dec 3 03:44:01 EST 2003


On Tue, 2 Dec 2003, Andrew Rucker Jones wrote:

> 3) One data corruption problem remains for sure, which i mentioned in
> the comments in the spp_stream4.c patch: if snort picks up a session in
> the middle, and nonzero window scales are in use, snort will not know
> that, and data corruption is certain to occur if large amounts of data
> are being transfered. As i also say in the comments, this is kind of
> unavoidable.

Yes, I have noticed this as well. It's very annoying when you have a merge
of two sessions in one alert payload.

> 2) Has anyone ever seen a case where one side of a connection
> acknowledges data that have not yet been sent? I swear that i have a
> real world capture (an e-mail to a Yahoo! address) in which the client
> sends data up to sequence number X, after which the server sends two
> ACKs right after each other: one for X, and one for X+1024 or so. Right
> after that, the client sends the next 1024 bytes. There are no
> retransmits involved. Of course, that causes data corruption, too, but
> snort can hardly be blamed for that. That entire conversation was just
> as weird as can be, i have to say.

Now, you seem to know your RFCs and TCP/IP in general, so I guess it is
not as easy as this, but given your description it could be:

If your client send a TCP packet with 1024 bytes of data, and this packet
have sequence number X, then the server will acknowledge this packet with
an ack number of X+1024.

Take a look at the three way handshake plus 1024 bytes of data:
---> SYN       Seq: X      Ack: 0 (nothing to ack yet)
<--- SYN ACK   Seq: Y      Ack: X+1 (SYN counts as 1)
---> ACK       Seq: X+1    Ack: Y+1
---> PSH ACK   Seq: X+1    Ack: Y+1   Data: <1024 bytes>
<--- ACK       Seq: Y+1    Ack: X+1+1024

/Martin





More information about the Snort-devel mailing list