From owner-freebsd-security@FreeBSD.ORG Wed Apr 21 05:10:57 2004 Return-Path: Delivered-To: freebsd-security@freebsd.org Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id 7A95D16A4CE; Wed, 21 Apr 2004 05:10:57 -0700 (PDT) Received: from sj-iport-3.cisco.com (sj-iport-3-in.cisco.com [171.71.176.72]) by mx1.FreeBSD.org (Postfix) with ESMTP id 5513D43D45; Wed, 21 Apr 2004 05:10:57 -0700 (PDT) (envelope-from rrs@cisco.com) Received: from sj-core-5.cisco.com (171.71.177.238) by sj-iport-3.cisco.com with ESMTP; 21 Apr 2004 04:22:39 +0000 Received: from mira-sjc5-c.cisco.com (IDENT:mirapoint@mira-sjc5-c.cisco.com [171.71.163.17]) by sj-core-5.cisco.com (8.12.10/8.12.6) with ESMTP id i3LCAs7t001803; Wed, 21 Apr 2004 05:10:55 -0700 (PDT) Received: from cisco.com (rtp-dial-1-162.cisco.com [10.83.97.162]) by mira-sjc5-c.cisco.com (MOS 3.4.5-GR) with ESMTP id ATF32354; Wed, 21 Apr 2004 05:10:52 -0700 (PDT) Message-ID: <408664C4.3060100@cisco.com> Date: Wed, 21 Apr 2004 07:10:44 -0500 From: "Randall Stewart (cisco)" User-Agent: Mozilla/5.0 (X11; U; FreeBSD i386; en-US; rv:1.4) Gecko/20031008 X-Accept-Language: en-us, en MIME-Version: 1.0 To: Don Lewis References: <200404210346.i3L3ki7E045504@gw.catspoiler.org> In-Reply-To: <200404210346.i3L3ki7E045504@gw.catspoiler.org> Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit X-Mailman-Approved-At: Thu, 22 Apr 2004 02:09:13 -0700 cc: freebsd-security@FreeBSD.org cc: avalon@caligula.anu.edu.au Subject: Re: [Full-Disclosure] IETF Draft - Fix for TCP vulnerability (fwd) X-BeenThere: freebsd-security@freebsd.org X-Mailman-Version: 2.1.1 Precedence: list List-Id: Security issues [members-only posting] List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 21 Apr 2004 12:10:57 -0000 Don Lewis wrote: >On 20 Apr, Don Lewis wrote: > > >>On 21 Apr, Darren Reed wrote: >> >> > > > >>>>http://www.ietf.org/internet-drafts/draft-ietf-tcpm-tcpsecure-00.txt >>>> >>>> >>I saw this draft earlier today. >> >> RFC793 [1] currently requires handling of a segment with the RST bit >> when in a synchronized state to be processed as follows: >> 1) If the RST bit is set and the sequence number is outside the >> expected window, silently drop the segment. >> 2) If the RST bit is set and the sequence number is acceptable i.e.: >> (RCV.NXT <= SEG.SEQ <= RCV.NXT+RCV.WND) then reset the connection. >> >> >> Instead, the following changes should be made to provide some >> protection against such an attack. >> A) If the RST bit is set and the sequence number is outside the >> expected window, silently drop the segment. >> B) If the RST bit is exactly the next expected sequence number, reset >> the connection. >> C) If the RST bit is set and the sequence number does not exactly >> match the next expected sequence value, yet is within the >> acceptable window (RCV.NXT < SEG.SEQ <= RCV.NXT+RCV.WND) send an >> acknowledgment. >> >> >>Our original implementation of the RST sequence number checking was much >>more permissive than RFC 793. I submitted a patch, which was included >>in tcp_input.c version 1.81 that implemented steps A and B above. It >>was discovered that this is incompatible with certain peers, so the code >>was changed to match RFC 793 in tcp_input.c 1.98. >> >>I don't know if adding step C will fix the problem. There may further >>info in the list archives. >> >> > >>From what I see here: > >I am concerned that step C will not solve the compatibility problem. The >FreeBSD host is sending a FIN to close an established connection, and >the peer host adding the window size advertised in the FIN packet to the >sequence number acknowledged in the FIN packet, and using the sum as the >sequence number for the RST packet, which puts the sequence number at >the end of the receive window. > > > > Don: Hmm we tested this in many forms... the FIN packet should be accepted since it does not have the RST bit set... at least if I understand your concern properly... If I am not understanding it the most that will happen is you delay closing the connection an extra RTT... Now OpenBSD has had the RST fix in .. or something like it for a long time.. they will not accept a RST unless the sequence no matches.. they do NOT send an ACK to illicit a response as step C puts in... so... I don't see this harmful.. R -- Randall R. Stewart ITD - Transport Technologies 815-477-2127(o) or 815-342-5222(c)