From owner-freebsd-security Wed May 5 16:47:46 1999 Delivered-To: freebsd-security@freebsd.org Received: from gatekeeper.tsc.tdk.com (gatekeeper.tsc.tdk.com [207.113.159.21]) by hub.freebsd.org (Postfix) with ESMTP id C47D614F81 for ; Wed, 5 May 1999 16:47:39 -0700 (PDT) (envelope-from gdonl@tsc.tdk.com) Received: from sunrise.gv.tsc.tdk.com (root@sunrise.gv.tsc.tdk.com [192.168.241.191]) by gatekeeper.tsc.tdk.com (8.8.8/8.8.8) with ESMTP id QAA22856; Wed, 5 May 1999 16:47:36 -0700 (PDT) (envelope-from gdonl@tsc.tdk.com) Received: from salsa.gv.tsc.tdk.com (salsa.gv.tsc.tdk.com [192.168.241.194]) by sunrise.gv.tsc.tdk.com (8.8.5/8.8.5) with ESMTP id QAA26024; Wed, 5 May 1999 16:47:35 -0700 (PDT) Received: (from gdonl@localhost) by salsa.gv.tsc.tdk.com (8.8.5/8.8.5) id QAA10103; Wed, 5 May 1999 16:47:34 -0700 (PDT) From: Don Lewis Message-Id: <199905052347.QAA10103@salsa.gv.tsc.tdk.com> Date: Wed, 5 May 1999 16:47:34 -0700 In-Reply-To: Don Lewis "Re: freebsd mbuf crash" (May 5, 4:15pm) X-Mailer: Mail User's Shell (7.2.6 alpha(3) 7/19/95) To: Don Lewis , The Tech-Admin Dude Subject: Re: freebsd mbuf crash Cc: freebsd-security@FreeBSD.ORG Sender: owner-freebsd-security@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.org On May 5, 4:15pm, Don Lewis wrote: } Subject: Re: freebsd mbuf crash } On May 5, 12:35am, The Tech-Admin Dude wrote: } } Subject: Re: freebsd mbuf crash } } Raise NMBCLUSTERS in kernel config file } } That's the fix for FreeBSD panics caused by running out of mbuf clusters. } } The exploit code that was posted triggered a bug in the IP reassembly code } that was present in 3.0 between August and October last year (ip_input.c } versions 1.100 through 1.102). I retract this statement. At first I thought the code was the nestea2 exploit from late last year, but I now believe it is a different exploit. It's use of a large number of IP options and fragmented TCP packets makes it resemble a potential way of sneaking TCP packets through a packet filtering firewall that filters by port numbers by overlaying the fragments so that the desired port number in the second fragment overwrites the port number in the first fragment that the firewall allowed through (but FreeBSD's IP reassembly algorithm never allowed FreeBSD to be attacked in this manner as an end system, so far as I know). This isn't what the code is trying to exploit, though. It's probably something related to fragment reassembly, IP option processing, or the sending of TCP RSTs in response to unsolicitied packets. To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-security" in the body of the message