From owner-freebsd-security Mon Jan 24 0: 2:33 2000 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 DCF9915200 for ; Mon, 24 Jan 2000 00:01:49 -0800 (PST) (envelope-from gdonl@tsc.tdk.com) Received: from imap.gv.tsc.tdk.com (imap.gv.tsc.tdk.com [192.168.241.198]) by gatekeeper.tsc.tdk.com (8.8.8/8.8.8) with ESMTP id AAA07927; Mon, 24 Jan 2000 00:01:38 -0800 (PST) (envelope-from gdonl@tsc.tdk.com) Received: from salsa.gv.tsc.tdk.com (salsa.gv.tsc.tdk.com [192.168.241.194]) by imap.gv.tsc.tdk.com (8.9.3/8.9.3) with ESMTP id AAA63120; Mon, 24 Jan 2000 00:01:37 -0800 (PST) (envelope-from Don.Lewis@tsc.tdk.com) Received: (from gdonl@localhost) by salsa.gv.tsc.tdk.com (8.8.5/8.8.5) id AAA21662; Mon, 24 Jan 2000 00:01:37 -0800 (PST) From: Don Lewis Message-Id: <200001240801.AAA21662@salsa.gv.tsc.tdk.com> Date: Mon, 24 Jan 2000 00:01:37 -0800 In-Reply-To: References: X-Mailer: Mail User's Shell (7.2.6 beta(5) 10/07/98) To: Bosko Milekic , Darren Reed Subject: Re: kernel panic's still due to mbuf problems. Cc: freebsd-security@FreeBSD.ORG Sender: owner-freebsd-security@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.org On Jan 23, 8:57pm, Bosko Milekic wrote: } Subject: Re: kernel panic's still due to mbuf problems. } } You know, "among all these `stream.c' Emails," I don't believe that I've } seen a single one that was worth being called a `bug report,' at all. } Unless I missed something after having adapted to the volume of } `stream.c' related junk by systematically deleting them, I don't believe } that I've seen any _detailed_ problem analysis, rather various } hypothesizing about nothing and everything all at once. Each of the incoming packets results in an outgoing RST packet and apparently these are expensive to generate. They also gobble up network bandwidth, which makes the DoS worse, and at least some of these, which are sent to the forged source addresses in the incoming packets, will trigger incoming ICMP unreachable packets. We need to rate limit the outgoing RST packets, which the current code does if we have ICMP_BANDLIM enabled, but only if the attack is directed at a port number that doesn't have a listening socket. If there is a socket listening at that port number, a different path is taken to the code that generates the RST packets that bypasses the rate limiter. At least some of the packets generated by stream.c have a bogus multicast source address, which the TCP stack happily accepts and sends its RST response to this multicast address (and the TCP stack will also accept a SYN packet with a multicast source address, set up a connection, and send the SYN-ACK response to this multicast address). The TCP stack should ignore packets with multicast or broadcast source addresses and should not respond to them. I posted a patch to fix these problems yesterday. To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-security" in the body of the message