TCP Segment Overwrites (Sig 1300) - Causes?

Unanswered Question
Sep 30th, 2003
User Badges:

I recently saw a number of hits against Signature 1300 - TCP Segment Overwrite. I am trying to figure out what could cause this condition. Has anyone else seen this in a normal connection?


Regards,


Chad

  • 1
  • 2
  • 3
  • 4
  • 5
Overall Rating: 5 (1 ratings)
Loading.
umedryk Mon, 10/06/2003 - 10:51
User Badges:
  • Bronze, 100 points or more

Only if the retransmitted data overwrites a different segment, sig 1300 alarms. Check that out...


mlhall Mon, 10/06/2003 - 11:06
User Badges:

I have several packet traces from several customers that see this alert. There appears to be a bug in the microsoft TCP stack when connections go stale. What happens is that the last successful segment's last byte is resent with a value of 0xff. This is after the other endhost has ACK'ed the sequence from the last segments.


So for example.


a->b seq=100 data="ABCDEFG"

b->a ack=107 no data

a->b seq=106 data="(0xff)"


The last packet in the example is overwriting the G in the first packet with an 0xff. This causes the IDS to fire. We are working on detecting this stack bug in a new version.




cgiulini Tue, 10/07/2003 - 12:03
User Badges:

I have a few traces to run through from the sensor.


Thanks for giving me somewhere to start looking.


Regards,


Chad



mlhall Fri, 01/23/2004 - 12:21
User Badges:

After further investigation I have found that there is an older implementation of TCP keepalives dating back to BSD 4.2 days where the keepalive does hold garbage data. Microsoft's stack was based on some of this older BSD code and therefore shows this behavior. So we have concluded that there is no stack bug in Microsoft's TCP stack. They are just doing something that most stacks do not.


We now know the problem and I will be committing a fix for v4.1.4 of the IDS. It will safely ignore an overwrite if it is a single byte one byte back in the sequence and both ends of the TCP connection have already ack'ed the byte.


Sorry for the delay in solving this problem for you all. If you have lowered the sev or filtered 1300 I would recommend setting your filters and severity back to default after upgrading to v4.1.4.


klwiley Mon, 01/26/2004 - 14:50
User Badges:
  • Cisco Employee,

4.1(4) has not been officially scheduled for release as yet. So we can not give a date for you. However there will be a 4.1(3d) patch made available that will include this fix in the next two weeks.


KLW

Actions

This Discussion