From owner-freebsd-questions Thu Nov 20 09:22:17 1997 Return-Path: Received: (from root@localhost) by hub.freebsd.org (8.8.7/8.8.7) id JAA19260 for questions-outgoing; Thu, 20 Nov 1997 09:22:17 -0800 (PST) (envelope-from owner-freebsd-questions) Received: from super-g.inch.com (super-g.com [207.240.140.161]) by hub.freebsd.org (8.8.7/8.8.7) with ESMTP id JAA19237; Thu, 20 Nov 1997 09:21:16 -0800 (PST) (envelope-from spork@super-g.com) Received: from localhost (localhost [127.0.0.1]) by super-g.inch.com (8.8.7/8.8.5) with SMTP id MAA12724; Thu, 20 Nov 1997 12:15:39 -0500 (EST) Date: Thu, 20 Nov 1997 12:15:39 -0500 (EST) From: spork X-Sender: spork@super-g.inch.com To: Matt Dillon cc: GNATS Management , freebsd-questions@FreeBSD.ORG Subject: Re: kern/5103: FreeBSD kernel lockup from spoofed TCP packet In-Reply-To: <199711201231.EAA01449@flea.best.net> Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Sender: owner-freebsd-questions@FreeBSD.ORG X-Loop: FreeBSD.org Precedence: bulk This is a nasty one, care to share your hack-patch? Charles Sprickman spork@super-g.com ---- "I'm not a prophet or a stone-age man Just a mortal with potential of a superman I'm living on" -DB On Thu, 20 Nov 1997, Matt Dillon wrote: > > >Number: 5103 > >Category: kern > >Synopsis: It appears to be possible to lockup a FreeBSD box with a spoofed TCP packet. Two of our shell machines were attacked tonight. > >Confidential: no > >Severity: critical > >Priority: high > >Responsible: freebsd-bugs > >State: open > >Class: sw-bug > >Submitter-Id: current-users > >Arrival-Date: Thu Nov 20 04:40:01 PST 1997 > >Last-Modified: > >Originator: Matt Dillon > >Organization: > Best Internet Communications > >Release: FreeBSD 2.2.5-STABLE i386 > >Environment: > > FreeBSD 2.2.5 running on PPro 200's > > >Description: > > Two of our machines were locked up tonight by what looks like a > spoofed TCP packet. The characteristics of the packet were that > both the source and destination address were set to the machine's > ethernet IP address, and the same tcp port was used for both source > and destination. > > We were able to core both machines from the debugger. Both kernels > were stuck in an endless ip_intr loop. It appeared that the tcp > stack transmitted a packet which caused the higher level ip_intr > to loop on tcp_input. An infinite loop ensued. > > >How-To-Repeat: > > Not sure. > > >Fix: > > not sure about this. I hacked our kernels to discard any packet > where ti_src.s_addr == ti_dst.s_addr && ti_sport == ti_dport. I > am hoping this will prevent the attack from looping the code. > > -Matt > > >Audit-Trail: > >Unformatted: >