From owner-freebsd-security Sat Jan 22 2:59:20 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 3C0E614F7B for ; Sat, 22 Jan 2000 02:59:17 -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 CAA20599; Sat, 22 Jan 2000 02:58:45 -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 CAA54402; Sat, 22 Jan 2000 02:58:45 -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 CAA16745; Sat, 22 Jan 2000 02:58:44 -0800 (PST) From: Don Lewis Message-Id: <200001221058.CAA16745@salsa.gv.tsc.tdk.com> Date: Sat, 22 Jan 2000 02:58:44 -0800 In-Reply-To: Vladimir Dubrovin "Re[2]: explanation and code for stream.c issues" (Jan 22, 1:41pm) X-Mailer: Mail User's Shell (7.2.6 beta(5) 10/07/98) To: Vladimir Dubrovin , Tim Yardley Subject: Re: Re[2]: explanation and code for stream.c issues Cc: 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, 1:41pm, Vladimir Dubrovin wrote: } Subject: Re[2]: explanation and code for stream.c issues } >>Attack can be easily changed to send pair SYN and invalid SYN/ACK } } My mistake here - SYN/ACK packet isn't required. Sorry, i wrote this } message after 11 hours of work. Only 11 hours, I've been here for 22, minus a couple hours of breaks. } Intruder sends SYN packet and then sends, lets say 1000 ACK packets to } the same port from same port and source address. SYN packet will open } ipfilter to pass all others packets. This attack doesn't need } randomization for each packet. Instead of producing RST responses, this will produce ACKs. Your earlier comment about this prompted my comment in another thread about the possible need to rate limit ACK packets. } By the way - published stream.c doesn't use ACK bit at all. } packet.tcp.th_flags = 0; There was a correction published that changed this to set the ACK bit. To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-security" in the body of the message