From owner-freebsd-net@FreeBSD.ORG Wed Feb 18 16:34:41 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 D660016A4CE for ; Wed, 18 Feb 2004 16:34:41 -0800 (PST) Received: from mailtoaster1.pipeline.ch (mailtoaster1.pipeline.ch [62.48.0.70]) by mx1.FreeBSD.org (Postfix) with ESMTP id 1058743D2D for ; Wed, 18 Feb 2004 16:34:41 -0800 (PST) (envelope-from andre@freebsd.org) Received: (qmail 43154 invoked from network); 19 Feb 2004 00:34:39 -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:34:39 -0000 Message-ID: <4034049A.906ACDB9@freebsd.org> Date: Thu, 19 Feb 2004 01:34:34 +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" References: <20040218220230.GF47727@madman.celabo.org> Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit cc: FreeBSD Security Officer Team cc: freebsd-net@freebsd.org 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:34:42 -0000 "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 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 > Cheers, > -- > Jacques Vidrine / nectar@celabo.org / jvidrine@verio.net / nectar@freebsd.org > > ----- Forwarded message from Baby Peanut ----- > > Date: Wed, 18 Feb 2004 06:21:25 -0800 (PST) > From: Baby Peanut > To: freebsd-security@freebsd.org > Subject: is this mbuf problem real? > Message-ID: <20040218142125.49433.qmail@web41902.mail.yahoo.com> > > BM_207650 > MEDIUM > Vulnerability > Version: 1 2/18/2004@03:47:29 GMT > Initial report > > ID#207650: > FreeBSD Memory Buffer Exhaustion Denial of Service Vulnerability > (iDEFENSE Exclusive): Remote exploitation of a denial of service (DoS) > vulnerability in FreeBSD's memory buffers (mbufs) could allow attackers > to launch a DoS attack. > > By sending many out-of-sequence packets, a low bandwidth denial of > service attack is possible against FreeBSD. When the targeted system > runs out of memory buffers (mbufs), it is no longer able to accept or > create new connections. > > Analysis: (iDEFENSE US) Exploitation of this vulnerability requires > that the targeted system has at least one open TCP port. > > The DoS will last until the port is closed, either by the attacker or > the target machine. > > Detection: iDEFENSE has confirmed this vulnerability exists in FreeBSD > 5.1 (default install from media). It is expected that it also exists > in earlier versions. > > Exploit: iDEFENSE has proof of concept exploit code demonstrating the > impact of this vulnerability. > > Vulnerability Types: Design Error - Denial of Service > Prevalence and Popularity: Almost always > Evidence of Active Exploitation or Probing: No known exploitation or > spike in probing > Ease of Exploitation: Remotely Exploitable > Existence and Availability of Exploit Code: An Exploit exists and is > closely traded. > Vulnerability Consequence: Availability > > __________________________________ > Do you Yahoo!? > Yahoo! Mail SpamGuard - Read only the mail you want. > http://antispam.yahoo.com/tools > _______________________________________________ > freebsd-security@freebsd.org mailing list > http://lists.freebsd.org/mailman/listinfo/freebsd-security > To unsubscribe, send any mail to "freebsd-security-unsubscribe@freebsd.org" > > ----- End forwarded message ----- > > _______________________________________________ > freebsd-net@freebsd.org mailing list > http://lists.freebsd.org/mailman/listinfo/freebsd-net > To unsubscribe, send any mail to "freebsd-net-unsubscribe@freebsd.org"