From owner-freebsd-current@FreeBSD.ORG Fri Feb 11 20:19:19 2005 Return-Path: Delivered-To: freebsd-current@freebsd.org Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id 5473D16A4CE for ; Fri, 11 Feb 2005 20:19:19 +0000 (GMT) Received: from c00l3r.networx.ch (c00l3r.networx.ch [62.48.2.2]) by mx1.FreeBSD.org (Postfix) with ESMTP id 09CD143D31 for ; Fri, 11 Feb 2005 20:19:18 +0000 (GMT) (envelope-from oppermann@networx.ch) Received: (qmail 41977 invoked from network); 11 Feb 2005 19:57:24 -0000 Received: from unknown (HELO networx.ch) ([62.48.0.54]) (envelope-sender ) by c00l3r.networx.ch (qmail-ldap-1.03) with SMTP for ; 11 Feb 2005 19:57:24 -0000 Message-ID: <420D1344.9DAC70D0@networx.ch> Date: Fri, 11 Feb 2005 21:19:16 +0100 From: Andre Oppermann X-Mailer: Mozilla 4.8 [en] (Windows NT 5.0; U) X-Accept-Language: en MIME-Version: 1.0 To: "Li, Qing" References: <00CDF9AA240E204FA6E923BD35BC64360879060E@bcs-mail.internal.cacheflow.com> Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit X-Mailman-Approved-At: Sat, 12 Feb 2005 13:15:21 +0000 cc: freebsd-net@freebsd.org cc: freebsd-current@freebsd.org Subject: Re: known TCP vulnerability ?? X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.1 Precedence: list List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 11 Feb 2005 20:19:19 -0000 "Li, Qing" wrote: > > http://www.kb.cert.org/vuls/id/464113 > > http://www.linuxsecurity.com/content/view/104980/98/ > > Ran the packet tests against FreeBSD 5.3 and 6-CURRENT and both > respond to the SYN+FIN packets with SYN+ACK. This is expected behaviour because of FreeBSD used to implement T/TCP according to RFC1644. I haven't removed this part from TCP because I have a better reincarnation of T/TCP without the previous shortcomings almost ready which uses this again. The CERT article describes how dumb firewalls with poor stateful inspection may get fooled by this and other flag combinations. All I can say is it's not our fault. The SYN+FIN combination is described in RFC1644 and if the firewall gets it wrong... Well, the real world sucks. > Should I file a PR if there isn't one already ?? No action required here. What you could check is whether our firewalls packages in stateful mode (ipfw, pf, ipfilter) can be fooled by this. I doubt it but if you can verify it, that would be great. -- Andre