Date: Mon, 24 Jan 2000 00:01:37 -0800 From: Don Lewis <Don.Lewis@tsc.tdk.com> To: Bosko Milekic <bmilekic@dsuper.net>, Darren Reed <avalon@coombs.anu.edu.au> Cc: freebsd-security@FreeBSD.ORG Subject: Re: kernel panic's still due to mbuf problems. Message-ID: <200001240801.AAA21662@salsa.gv.tsc.tdk.com> In-Reply-To: <Pine.OSF.4.05.10001232048190.17723-100000@oracle.dsuper.net> References: <Pine.OSF.4.05.10001232048190.17723-100000@oracle.dsuper.net>
next in thread | previous in thread | raw e-mail | index | archive | help
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
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?200001240801.AAA21662>