From owner-freebsd-net@FreeBSD.ORG Wed Feb 18 16:47:30 2004 Return-Path: Delivered-To: freebsd-net@freebsd.org Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id 8CCC716A4CE for ; Wed, 18 Feb 2004 16:47:30 -0800 (PST) Received: from mailtoaster1.pipeline.ch (mailtoaster1.pipeline.ch [62.48.0.70]) by mx1.FreeBSD.org (Postfix) with ESMTP id CE0D643D2D for ; Wed, 18 Feb 2004 16:47:29 -0800 (PST) (envelope-from andre@freebsd.org) Received: (qmail 43992 invoked from network); 19 Feb 2004 00:47:28 -0000 Received: from unknown (HELO freebsd.org) ([62.48.0.54]) (envelope-sender ) by mailtoaster1.pipeline.ch (qmail-ldap-1.03) with SMTP for ; 19 Feb 2004 00:47:28 -0000 Message-ID: <4034079B.8C29425C@freebsd.org> Date: Thu, 19 Feb 2004 01:47:23 +0100 From: Andre Oppermann X-Mailer: Mozilla 4.76 [en] (Windows NT 5.0; U) X-Accept-Language: en MIME-Version: 1.0 To: "Jacques A. Vidrine" , freebsd-net@freebsd.org, FreeBSD Security Officer Team References: <20040218220230.GF47727@madman.celabo.org> <4034049A.906ACDB9@freebsd.org> Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Subject: Re: Fwd: [is this mbuf problem real?] X-BeenThere: freebsd-net@freebsd.org X-Mailman-Version: 2.1.1 Precedence: list List-Id: Networking and TCP/IP with FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 19 Feb 2004 00:47:30 -0000 Andre Oppermann wrote: > > "Jacques A. Vidrine" wrote: > > > > Does anyone have time to investigate? I will try to get more > > information from iDEFENSE. > > Looking at the code there are indeed some problems. > > - there seems to be no boundary on how many segments we keep in the > tcp reassembly queue > - there seems to be no timeout of overaged fragments (we can drop > the segments after 1*msl because we don't have SACK and it has > to be retransmitted anyway since not ACK'ed which happens after > read from userland). Possibly it can be dropped earlier after > we've got x bytes or packets of more segments since it is un- > likely to receive the missing packet this late except for really > massive reordering > - this attack can be made with small packets which consume an mbuf > cluster anyway - it uses MALLOC() to allocate its queue entry wheras it probably should use the zone allocator. The max limit on the zone than directly gives us a upper limit on the number of concatenated segments (not mbufs) - it uses LIST_FOREACH which is pretty inefficient. NetBSD has optimized this part quite a bit with a tail queue > For IP packet reassembly we have global and local limits: > > net.inet.ip.maxfragpackets: 800 > net.inet.ip.maxfragsperpacket: 16 > > Something like this is needed for TCP as well to cope with this kind > of resource exhaustion attack. > > I can fix this stuff but I won't be able to do that in emergency mode. > The first code can be ready after the weekend. If someone else wants > to takle it earlier/faster tell me. -- Andre