From owner-freebsd-stable Fri Apr 6 21:19:10 2001 Delivered-To: freebsd-stable@freebsd.org Received: from bilbo.marshall.edu (bilbo.MARSHALL.EDU [206.212.27.123]) by hub.freebsd.org (Postfix) with ESMTP id 6BA1E37B422 for ; Fri, 6 Apr 2001 21:19:08 -0700 (PDT) (envelope-from haught12@marshall.edu) Received: from 0 (webmail.MARSHALL.EDU [206.212.27.46]) by marshall.edu (PMDF V5.2-33 #37574) with ESMTP id <01K22ZNJBOA68Y5DVZ@marshall.edu> for freebsd-stable@freebsd.org; Fri, 6 Apr 2001 14:31:18 EST Date: Fri, 06 Apr 2001 14:38:20 -0400 From: Matt Haught Subject: IP Filter =?iso-8859-1?q?3.4.17=3F?= To: freebsd-stable@freebsd.org Message-id: <01K22ZNJBR3K8Y5DVZ@marshall.edu> MIME-version: 1.0 Content-type: text/plain; charset=iso-8859-1 Content-transfer-encoding: 8bit User-Agent: IMHO/0.98.1 (Webmail for Roxen) Sender: owner-freebsd-stable@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.ORG Is it too late to update ipfilter in -STABLE? 3.4.16 seems to have a serious bug. Darren just sent out this to the ipfilter mailling list: -----snip---- A *VERY* serious bug has been brought to my attention in IPFilter. In 10 words or less, fragment caching with can let through "any" packet. Ok, so that's 8. Cause ===== When matching a fragment, only srcip, dstip and IP ID# are checked and the fragment cache is checked *before* any rules are checked. It does not even need to be a fragment. Even if you block all fragments with a rule, fragment cache entries can be created by packets that match state information currently held. ------snip---- -Matt To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-stable" in the body of the message