[13521] in bugtraq
Re: explanation and code for stream.c issues
daemon@ATHENA.MIT.EDU (Don Lewis)
Sun Jan 23 23:13:06 2000
Message-Id: <200001221058.CAA16745@salsa.gv.tsc.tdk.com>
Date: Sat, 22 Jan 2000 02:58:44 -0800
Reply-To: Don Lewis <Don.Lewis@TSC.TDK.COM>
From: Don Lewis <Don.Lewis@TSC.TDK.COM>
X-To: Vladimir Dubrovin <vlad@sandy.ru>, Tim Yardley <yardley@uiuc.edu>
To: BUGTRAQ@SECURITYFOCUS.COM
In-Reply-To: Vladimir Dubrovin <vlad@sandy.ru> "Re[2]: explanation and code
for stream.c issues" (Jan 22, 1:41pm)
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.
