In some mail from Brett Glass, sie said:
>
> At 06:03 PM 1/20/2000 , Darren Reed wrote:
>
> >If you're using "flags S keep state" or "flags S/SA keep state",
> >then as far as I'm aware, having read the code, you are safe.
>
> This might be a workaround. What rule(s) would have to follow it
> to block the ACK?
None.
> >I'm intrigued to know what the bug is. Reading the code, it is
> >hard to see how you could make a box fall over using it, unless
> >there were some serious problems in how random TCP ACK's were
> >handled.
>
> My guess is that there's a long code path, or other inefficiency,
> in the way the ACK is handled. Perhaps a linear search for the
> right socket instead of one that's more clevery implemented
> (e.g. search by port, then address, etc.).
Well, it does bring Solaris7 to a point where it runs _very_ slowly:
# ping -s 10.100.1.2
PING 10.100.1.2: 56 data bytes
64 bytes from solaris7 (10.100.1.2): icmp_seq=0. time=2. ms
64 bytes from solaris7 (10.100.1.2): icmp_seq=1. time=0. ms
64 bytes from solaris7 (10.100.1.2): icmp_seq=2. time=0. ms
64 bytes from solaris7 (10.100.1.2): icmp_seq=3. time=0. ms
64 bytes from solaris7 (10.100.1.2): icmp_seq=4. time=0. ms
64 bytes from solaris7 (10.100.1.2): icmp_seq=5. time=0. ms
64 bytes from solaris7 (10.100.1.2): icmp_seq=6. time=0. ms
64 bytes from solaris7 (10.100.1.2): icmp_seq=7. time=0. ms
64 bytes from solaris7 (10.100.1.2): icmp_seq=8. time=0. ms
64 bytes from solaris7 (10.100.1.2): icmp_seq=9. time=0. ms
64 bytes from solaris7 (10.100.1.2): icmp_seq=10. time=0. ms -- start
64 bytes from solaris7 (10.100.1.2): icmp_seq=11. time=11. ms
64 bytes from solaris7 (10.100.1.2): icmp_seq=12. time=16. ms
64 bytes from solaris7 (10.100.1.2): icmp_seq=13. time=16. ms
64 bytes from solaris7 (10.100.1.2): icmp_seq=14. time=18. ms
64 bytes from solaris7 (10.100.1.2): icmp_seq=15. time=21. ms
64 bytes from solaris7 (10.100.1.2): icmp_seq=17. time=23. ms
64 bytes from solaris7 (10.100.1.2): icmp_seq=19. time=25. ms
64 bytes from solaris7 (10.100.1.2): icmp_seq=22. time=29. ms
64 bytes from solaris7 (10.100.1.2): icmp_seq=28. time=21. ms
64 bytes from solaris7 (10.100.1.2): icmp_seq=36. time=0. ms -- end
64 bytes from solaris7 (10.100.1.2): icmp_seq=37. time=0. ms
64 bytes from solaris7 (10.100.1.2): icmp_seq=38. time=0. ms
64 bytes from solaris7 (10.100.1.2): icmp_seq=39. time=0. ms
^C
----10.100.1.2 PING Statistics----
40 packets transmitted, 24 packets received, 40% packet loss
round-trip (ms) min/avg/max = 0/7/29
#
FWIW, the box sending the ping's and solaris7 are 100BaseT
but the attacker is only 10BaseT. Besides the issue of time
to process TCP packets, there is also basic network flooding
happening here too.
Darren
To Unsubscribe: send mail to [EMAIL PROTECTED]
with "unsubscribe freebsd-stable" in the body of the message
