[13509] in bugtraq

home help back first fref pref prev next nref lref last post

Re: explanation and code for stream.c issues

daemon@ATHENA.MIT.EDU (Vladimir Dubrovin)
Sun Jan 23 18:57:45 2000

Mime-Version: 1.0
Content-Type: text/plain; charset=us-ascii
Content-Transfer-Encoding: 7bit
Message-Id:  <1593.000122@sandy.ru>
Date:         Sat, 22 Jan 2000 14:14:29 +0300
Reply-To: Vladimir Dubrovin <vlad@sandy.ru>
From: Vladimir Dubrovin <vlad@SANDY.RU>
X-To:         Don Lewis <Don.Lewis@tsc.tdk.com>
To: BUGTRAQ@SECURITYFOCUS.COM
In-Reply-To:  <200001221058.CAA16745@salsa.gv.tsc.tdk.com>

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

    packet.tcp.th_ack           = 0;

i changed to

    packet.tcp.th_ack = random();
    for ACK packets.

But  it's  not  principial  - victim will reply RST for this packet in
most cases.


  +=-=-=-=-=-=-=-=-=+
  |Vladimir Dubrovin|
  | Sandy Info, ISP |
  +=-=-=-=-=-=-=-=-=+

home help back first fref pref prev next nref lref last post