From owner-freebsd-security@FreeBSD.ORG Tue Apr 20 20:12:14 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 1957E16A4CE for ; Tue, 20 Apr 2004 20:12:14 -0700 (PDT) Received: from gw.catspoiler.org (217-ip-163.nccn.net [209.79.217.163]) by mx1.FreeBSD.org (Postfix) with ESMTP id 0D85643D46 for ; Tue, 20 Apr 2004 20:12:13 -0700 (PDT) (envelope-from truckman@FreeBSD.org) Received: from FreeBSD.org (mousie.catspoiler.org [192.168.101.2]) by gw.catspoiler.org (8.12.9p2/8.12.9) with ESMTP id i3L3Bt7E045458; Tue, 20 Apr 2004 20:11:59 -0700 (PDT) (envelope-from truckman@FreeBSD.org) Message-Id: <200404210311.i3L3Bt7E045458@gw.catspoiler.org> Date: Tue, 20 Apr 2004 20:11:55 -0700 (PDT) From: Don Lewis To: avalon@caligula.anu.edu.au In-Reply-To: <200404210158.i3L1wxoM010197@caligula.anu.edu.au> MIME-Version: 1.0 Content-Type: TEXT/plain; charset=us-ascii cc: freebsd-security@FreeBSD.org 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 03:12:14 -0000 On 21 Apr, Darren Reed wrote: > Forwarded message: >> From full-disclosure-admin@lists.netsys.com Wed Apr 21 11:49:12 2004 >> To: full-disclosure@lists.netsys.com >> From: Darren Bounds >> Subject: [Full-Disclosure] IETF Draft - Fix for TCP vulnerability >> Date: Tue, 20 Apr 2004 18:19:58 -0400 >> >> -----BEGIN PGP SIGNED MESSAGE----- >> Hash: SHA1 >> >> 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.