From owner-freebsd-security Sat Jan 22 4: 3:35 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 5344E14EDD for ; Sat, 22 Jan 2000 04:03:33 -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 EAA22190; Sat, 22 Jan 2000 04:03:23 -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 EAA56559; Sat, 22 Jan 2000 04:03:22 -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 EAA16975; Sat, 22 Jan 2000 04:03:20 -0800 (PST) From: Don Lewis Message-Id: <200001221203.EAA16975@salsa.gv.tsc.tdk.com> Date: Sat, 22 Jan 2000 04:03:19 -0800 In-Reply-To: <1593.000122@sandy.ru> References: <200001221058.CAA16745@salsa.gv.tsc.tdk.com> <1593.000122@sandy.ru> X-Mailer: Mail User's Shell (7.2.6 beta(5) 10/07/98) To: Vladimir Dubrovin , Don Lewis Subject: Re: Re[4]: explanation and code for stream.c issues Cc: Tim Yardley , news@technotronic.com, bugtraq@securityfocus.com, freebsd-security@FreeBSD.ORG Sender: owner-freebsd-security@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.org On Jan 22, 2:14pm, Vladimir Dubrovin wrote: } Subject: Re[4]: explanation and code for stream.c issues } Hello Don Lewis, } } 22.01.00 13:58, you wrote: explanation and code for stream.c issues; } } D> } Intruder sends SYN packet and then sends, lets say 1000 ACK packets to } D> } the same port from same port and source address. SYN packet will open } D> } ipfilter to pass all others packets. This attack doesn't need } D> } randomization for each packet. } } D> Instead of producing RST responses, this will produce ACKs. Your earlier } D> comment about this prompted my comment in another thread about the } D> possible need to rate limit ACK packets. } } This will not produce ACK packets, if ACK send by intruder doesn't } conform sequence number in the SYN/ACK response of victim. Original } stream.c used [snip] } But it's not principial - victim will reply RST for this packet in } most cases. Ok, you are correct. The attacker would have to guess or sniff the initial sequence number in order to produce a flood of ACK responses, so the stack is in better shape than I feared. I'm getting too tired to really analyze this, but I also think that repeatedly sending the original SYN (sorry for the pun) won't cause a flood of responses. I think the victim will periodically resend the SYN+ACK packet for which it expects an ACK. To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-security" in the body of the message