Date: Sat, 22 Nov 1997 03:25:54 -0800 From: Don Lewis <Don.Lewis@tsc.tdk.com> To: Darren Reed <avalon@coombs.anu.edu.au>, Don.Lewis@tsc.tdk.com (Don Lewis) Cc: jas@flyingfox.com, robert@cyrus.watson.org, security@freebsd.org Subject: Re: new TCP/IP bug in win95 (fwd)g Message-ID: <199711221125.DAA17122@salsa.gv.tsc.tdk.com> In-Reply-To: Darren Reed <avalon@coombs.anu.edu.au> "Re: new TCP/IP bug in win95 (fwd)g" (Nov 22, 5:26pm)
next in thread | previous in thread | raw e-mail | index | archive | help
On Nov 22, 5:26pm, Darren Reed wrote: } Subject: Re: new TCP/IP bug in win95 (fwd)g } In some mail from Don Lewis, sie said: } > } > I like the following patch better since it is both smaller and doesn't } > require investigating all the different possible relationships between } > sequence numbers. Comments? } Hmmm, "doesn't require" checking seq/ack #'s ? This check is in addition to the existing sequence number checks which follow it. The problem with doing the sequence number checks first is that if the SYN flag falls outside the receive window, the SYN flag gets cleared, which means we will skip the test later in the code that will drop the segment if we have an inappropriate SYN flag. This results in the connection possibly going into the ESTABLISHED state with itself and/or getting into an ACK war with itself. My previous patch attempted to do a sequence number check and only drop the segment if the check failed (but it botched this because it didn't verify that the ACK bit was set before doing this test). I was uncomfortable with this because I wasn't sure that all the SYN,ACK packets that passed that test would be caught and dropped later in the code. I now feel it's safer to just drop the segment if we get a SYN,ACK, since that should never happen in the SYN_RCVD state. I believe there are only two valid segments that we can receive in this state. Normally we should get an ACK in response to our SYN,ACK. If our SYN,ACK is lost, then the remote host should time out and resend the initial SYN packet. If we receive a SYN,ACK, then something is definitely wrong and we should drop the segment and send a RST. In addition to hanging the system by sending a spoofed SYN with identical source and destination endpoints, I think it is also possible to get two hosts into an ACK war and cause them to burn a lot of bandwidth by sending each of them spoofed SYNs with each other as the source. They'll each eventually time out the connections because they'll never receive the correct ACK, so this is not a fatal DOS. My patch should cause each of them to send a RST to the other, which will cause each them to drop the connection created by the initial spoofed SYNs. This is a much quicker and less expensive recovery. } The seq/ack numbers make up 66% of the validation that a TCP packet is part } of an active stream. The other 33% is the source and destination port. The connection isn't yet in an ESTABLISHED state, it's still in SYN_RCVD.
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?199711221125.DAA17122>