[13524] in bugtraq
Re: explanation and code for stream.c issues
daemon@ATHENA.MIT.EDU (Don Lewis)
Mon Jan 24 00:19:27 2000
Message-Id: <200001221203.EAA16975@salsa.gv.tsc.tdk.com>
Date: Sat, 22 Jan 2000 04:03:19 -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>
To: BUGTRAQ@SECURITYFOCUS.COM
In-Reply-To: <1593.000122@sandy.ru>
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.
