Date: Sat, 22 Jan 2000 02:58:44 -0800 From: Don Lewis <Don.Lewis@tsc.tdk.com> To: Vladimir Dubrovin <vlad@sandy.ru>, Tim Yardley <yardley@uiuc.edu> Cc: news@technotronic.com, bugtraq@securityfocus.com, freebsd-security@FreeBSD.ORG Subject: Re: Re[2]: explanation and code for stream.c issues Message-ID: <200001221058.CAA16745@salsa.gv.tsc.tdk.com> In-Reply-To: Vladimir Dubrovin <vlad@sandy.ru> "Re[2]: explanation and code for stream.c issues" (Jan 22, 1:41pm)
next in thread | previous in thread | raw e-mail | index | archive | help
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
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?200001221058.CAA16745>