Date: Fri, 21 Jan 2000 17:29:45 -0600 From: Tim Yardley <yardley@uiuc.edu> To: BUGTRAQ@SECURITYFOCUS.COM, freebsd-security@FreeBSD.ORG Subject: Re: explanation and code for stream.c issues Message-ID: <4.2.0.58.20000121162825.01374f10@students.uiuc.edu> In-Reply-To: <4.2.0.58.20000121113943.012a8f10@students.uiuc.edu> References: <4.2.0.58.20000121112253.012a8f10@students.uiuc.edu>
next in thread | previous in thread | raw e-mail | index | archive | help
>>If you use ipfilter... ANY stateful (state based) firewall can be used to stop this as the intermediate fix. I apologize for not making that clear. >>Otherwise, wait for vendor patches. >> >>FreeBSD "unofficial patch" by Alfred Perlstein: >>http://www.freebsd.org/~alfred/tcp_fix.diff The vendor patches should consist of RST bandwidth limiting and a few optimizations (to help a little more). The patches should take them all of a few hours at most. >> packet.tcp.th_flags = 0; > >change this to a little different effect: > >packet.tcp.th_flags = TH_ACK; I have been getting mailed a lot about this. Here is why I said the previous statement. Receiving a packet with no flags is considered an illegal packet (obviously) and is often dumped, however, as we have seen in the past.. illegal packets often wreak havoc and often go untested. There is very little that "raped.c" or "stream.c" show as problems in the TCP/IP stacks. The true problem lies more in the effects of the response (caused by the attack). This is the same concept as the SYN floods of yesteryear, and the same type of thing will be done to handle it. The main difference is that it will be on a simpler note because there isn't much need for a "cookie" based system. One should just throttle the response of the reset packets which in turn will help stop the storm that you generate. The main effect of this attack is that you are shooting back RST's at all the spoofed hosts. Obviously, a lot of these hosts will not exist and you will get ICMP unreaches (as an example) bounced back at you. There are other possibilities as well, but unreach would be the most common (redirects might be common as well although i did not spend the time to analyze that). The ones that don't respond back may send you some packets back as well (depending on if the port was valid or not and what their firewall rules are). This causes a nice little storm of packets, in the ideal case. Note that I said ideal case in the previous paragraph. This is not always the observed behavior. It all depends on what is on the subnet, what type of packets are recieved, what rules and filters you have setup, and even the duration of the flood. It has been pointed out several times that the machine will go back to normal once the attack is stopped, which is exactly why something like RST_BANDLIM will work. I have also been asked a lot about what this "bug" affects. I have seen it have effects on *BSD, Linux, Solaris, and Win* as far as OS's go. It has also seemed to affect some hubs, switches, routers, or gateways since entire subnets have "disappeared" briefly after the attack. I don't have more specifics on it since I do not directly know the people that operated those networks, it was just discovered in the testing period. It should be noted that FreeBSD 3.4 and -CURRENT both have the TCP_RESTRICT_RST option. You can turn on tcp_restrict_rst by recompile your kernel with option TCP_RESTRICT_RST and then turn on tcp_restrict_rst in /etc/rc.conf. I hope that this helps, or explains a little more at least. /tmy -- Diving into infinity my consciousness expands in inverse proportion to my distance from singularity +-------- ------- ------ ----- ---- --- -- ------ --------+ | Tim Yardley (yardley@uiuc.edu) | http://www.students.uiuc.edu/~yardley/ +-------- ------- ------ ----- ---- --- -- ------ --------+ 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?4.2.0.58.20000121162825.01374f10>