From owner-cvs-all@FreeBSD.ORG Thu Jan 8 10:03:48 2004 Return-Path: Delivered-To: cvs-all@freebsd.org Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id 0536D16A4D0 for ; Thu, 8 Jan 2004 10:03:48 -0800 (PST) Received: from mailtoaster1.pipeline.ch (mailtoaster1.pipeline.ch [62.48.0.70]) by mx1.FreeBSD.org (Postfix) with ESMTP id 6FA6E43D54 for ; Thu, 8 Jan 2004 10:03:31 -0800 (PST) (envelope-from andre@freebsd.org) Received: (qmail 70748 invoked from network); 8 Jan 2004 18:03:30 -0000 Received: from unknown (HELO freebsd.org) ([62.48.0.53]) (envelope-sender ) by mailtoaster1.pipeline.ch (qmail-ldap-1.03) with SMTP for ; 8 Jan 2004 18:03:30 -0000 Message-ID: <3FFD9B72.C3BD7F3C@freebsd.org> Date: Thu, 08 Jan 2004 19:03:30 +0100 From: Andre Oppermann X-Mailer: Mozilla 4.76 [en] (Windows NT 5.0; U) X-Accept-Language: en MIME-Version: 1.0 To: src-committers@FreeBSD.org, cvs-src@FreeBSD.org, cvs-all@FreeBSD.org References: <200401081740.i08He8J9063202@repoman.freebsd.org> Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Subject: Re: cvs commit: src/sys/netinet ip_icmp.c tcp.h tcp_input.c tcp_subr.ctcp_usrreq.c tcp_var.h X-BeenThere: cvs-all@freebsd.org X-Mailman-Version: 2.1.1 Precedence: list List-Id: CVS commit messages for the entire tree List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 08 Jan 2004 18:03:48 -0000 Andre Oppermann wrote: > > andre 2004/01/08 09:40:07 PST > > FreeBSD src repository > > Modified files: > sys/netinet ip_icmp.c tcp.h tcp_input.c tcp_subr.c > tcp_usrreq.c tcp_var.h > Log: > Limiters and sanity checks for TCP MSS (maximum segement size) > resource exhaustion attacks. The fix for 4-STABLE is here: http://www.nrg4u.com/freebsd/tcpminmss-4stable-20040107.diff As usual if there are any problems contact me immediatly. Especially when you see any disconnects during nomal activity. It might be that I've missed a scenario or case where an application is legitimatly sending more than 1,000 small tcp segements per second. However I've looked and tried hard to find one. -- Andre > For network link optimization TCP can adjust its MSS and thus > packet size according to the observed path MTU. This is done > dynamically based on feedback from the remote host and network > components along the packet path. This information can be > abused to pretend an extremely low path MTU. > > The resource exhaustion works in two ways: > > o during tcp connection setup the advertized local MSS is > exchanged between the endpoints. The remote endpoint can > set this arbitrarily low (except for a minimum MTU of 64 > octets enforced in the BSD code). When the local host is > sending data it is forced to send many small IP packets > instead of a large one. > > For example instead of the normal TCP payload size of 1448 > it forces TCP payload size of 12 (MTU 64) and thus we have > a 120 times increase in workload and packets. On fast links > this quickly saturates the local CPU and may also hit pps > processing limites of network components along the path. > > This type of attack is particularly effective for servers > where the attacker can download large files (WWW and FTP). > > We mitigate it by enforcing a minimum MTU settable by sysctl > net.inet.tcp.minmss defaulting to 256 octets. > > o the local host is reveiving data on a TCP connection from > the remote host. The local host has no control over the > packet size the remote host is sending. The remote host > may chose to do what is described in the first attack and > send the data in packets with an TCP payload of at least > one byte. For each packet the tcp_input() function will > be entered, the packet is processed and a sowakeup() is > signalled to the connected process. > > For example an attack with 2 Mbit/s gives 4716 packets per > second and the same amount of sowakeup()s to the process > (and context switches). > > This type of attack is particularly effective for servers > where the attacker can upload large amounts of data. > Normally this is the case with WWW server where large POSTs > can be made. > > We mitigate this by calculating the average MSS payload per > second. If it goes below 'net.inet.tcp.minmss' and the pps > rate is above 'net.inet.tcp.minmssoverload' defaulting to > 1000 this particular TCP connection is resetted and dropped. > > MITRE CVE: CAN-2004-0002 > Reviewed by: sam (mentor) > MFC after: 1 day > > Revision Changes Path > 1.87 +4 -2 src/sys/netinet/ip_icmp.c > 1.19 +19 -1 src/sys/netinet/tcp.h > 1.219 +60 -0 src/sys/netinet/tcp_input.c > 1.174 +24 -0 src/sys/netinet/tcp_subr.c > 1.91 +2 -1 src/sys/netinet/tcp_usrreq.c > 1.94 +7 -0 src/sys/netinet/tcp_var.h