From owner-freebsd-security Tue Jan 25 13:15:29 2000 Delivered-To: freebsd-security@freebsd.org Received: from mail.servercom.com (mail.servercom.com [198.76.116.6]) by hub.freebsd.org (Postfix) with ESMTP id 101ED14C87 for ; Tue, 25 Jan 2000 13:15:16 -0800 (PST) (envelope-from yardley@uiuc.edu) Received: from liquid (wake-gw.wakeland.servercom.com [198.88.186.1]) by mail.servercom.com (Post.Office MTA v3.5.3 release 223 ID# 0-57662U1200L100S0V35) with ESMTP id com for ; Tue, 25 Jan 2000 15:12:57 -0600 Message-Id: <4.2.0.58.20000125151430.01234f10@students.uiuc.edu> X-Sender: yardley@students.uiuc.edu X-Mailer: QUALCOMM Windows Eudora Pro Version 4.2.0.58 Date: Tue, 25 Jan 2000 15:15:16 -0600 To: freebsd-security@FreeBSD.ORG From: Tim Yardley Subject: Fwd: multicasts from hell Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii"; format=flowed Sender: owner-freebsd-security@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.org Thought this might interest some of you... since all the multicast talk is going on. /tmy >Approved-By: aleph1@SECURITYFOCUS.COM >Delivered-To: bugtraq@lists.securityfocus.com >Delivered-To: bugtraq@securityfocus.com >X-Sender: yardley@students.uiuc.edu >X-Mailer: QUALCOMM Windows Eudora Pro Version 4.2.0.58 >Date: Tue, 25 Jan 2000 09:39:47 -0600 >Reply-To: Tim Yardley >Sender: Bugtraq List >From: Tim Yardley >Subject: multicasts from hell >X-To: bugtraq@securityfocus.com >To: BUGTRAQ@SECURITYFOCUS.COM > >a new look... multicasts from hell.. courtesy of spank.c >by Tim Yardley [yardley@uiuc.edu -- lst @ efnet] > >--------------------------------------------------- >:: temp remedy (exec summary) >--------------------------------------------------- > >If you use ipfilter... This *MAY* help you... but the issue is quite a bit >different than the previous issue. > >-- start rule set -- >block in quick proto tcp from any to any head 100 >block in quick proto tcp from 224.0.0.0/28 to any group 100 >pass in quick proto tcp from any to any flags S keep state group 100 >pass out proto tcp from any to any flags S keep state >pass in all >-- end rule set -- > >optionally, a rule like the following could be inserted to handle outgoing >packets (if they send from the firewall somehow) but you have bigger >problems than the attack if that is the case. > >-- start additional rule -- >block out proto tcp from any to 224.0.0.0/28 >-- end additional rule -- > >That will help you "stop" the attack (actually it will just help minimize >the affects), although it will still use some CPU though > >Note: If you use IPFW, there is no immediate way to solve this problem due >to the fact that it is a stateless firewall and you are dealing with >packets that are being forged with invalid (or possibly even valid >flags). You can however use IPFW or any other firewall to block out >packets from multicasts. If you are getting attacked, then temporarily use >ipfilter (or any other state based firewall) to slow the affects, ie keep >track of the states. Otherwise, wait for vendor patches or read more about >the explanation for other possible workarounds. > >-- ipfw rule for multicasts (with cars for the command and interface -- >change accordingly) --- >$fwcmd add deny all from 224.0.0.0/28 to any via ${oif} >-- end ipfw rule -- > >FreeBSD "unofficial patch" by Don Lewis: >http://solid.ncsa.uiuc.edu/~liquid/patch/don_lewis_tcp.diff > >------------------------------------------------ >:: explanation of spank.c attack >------------------------------------------------ > >NOTE: For this attack to work, you must have multicast enabled on the >network that you are attacking from, otherwise the packets should just get >dropped. The adverse affect of this, is that it seems to destroy the local >net, and the affect on the remote net is unknown (since the localnet dies >too quickly). This could become a problem with distributed DoS systems >because if a host on your internal net is compromised, then they can bring >your entire internal net down to a screaching halt. > >This is a tad different than the previous release. Stream/Raped mearly >flooded the host with ack's (or no flags) and came from random ips with >random sequence numbers and/or ack numbers. The difference now is that >this not only does the previous stuff, but also directly attacks from and >to multicast addresses as well. There are also options to randomize the >attack more. Just as before, rate limiting should be done to counteract its >effect (the same idea as ICMP_BANDLIM).. and also the multicast handling in >the stack should be checked to verify that it is behaving properly. > >The attacker specifies the port[s] that they want to send the attack to, >depending on what ports are selected, you will have different net >results. If the port is an open port, then you will possibly have a longer >kernel path to follow before the drop. Therefore, a smart attacker will >hit open ports, but havoc can also come about from random ports due to >states and processing. > >In the best case scenario, you will experience only the lag of the flood >and the lag of the processing (currently) and then be fine when the >attacker stops, In the worst case, you lockup, kill the network, and >possibly have to reboot. Once you patch it, you deal with a lot less >processing time (the drops are handled without the RST flag when >appropriate -- bandlim type idea). In other words, you go to the drop >routine instead of dropwithrst silencing your response, which decreases >your processing time, the hit on your network, and the effect of the flood >(once a threshold is reached, all those bad packets are silently dropped >and the attack has less of a net effect). There are issues with not >producing RST's since they were put into the specs for a reason, so blindly >dropping all RST's is not a good plan. > >The filters that were presented at the beginning of this email will block >all multicast packets that come in (and possibly out) of the tcp stack. I >have been getting mailed a lot about the previous attack. It should be >noted that 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. Hence the >reasoning behind the '-r' flag of this. > >There is very little that "raped.c" or "stream.c" actually showed 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 and in general, harden the tcp/ip stack to behave the way it >is supposed to in adverse conditions. > >The main effect of this attack is that you are shooting back RST+ACK's at >all the spoofed hosts. In the case of the new attacks, this happens to >mean that you are directing them at multicast addresses. 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 type of >attack is complicated by the multicasts, and the effect is amplified as >well. All in all, it becomes very nasty very quick. Basically, 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 ICMP_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 (due to >the previous stuff). The new multicast code seems to affect the local lan >(routers, gateways, and switches) more so than it affects anything else but >due to how it works (when it works), it is somewhat difficult to >test. Therefore, no blame is being directly placed on any specific >platform or architecture. Entire subnets have "disappeared" briefly after >the attack and have required route purgings to correct the issue. The >multicast attack seems to be more deadly to the network than the previous >attack and its affects get amplified and even carried over to the rest of >the network (bypassing secluded network bounds). I don't have more >specifics on the systems affected because of the difficulty in testing it >(and keeping the network up) since I do not have local access to the >networks that I tested on, and remote access gets real ugly real >fast. Everyone elses mileage may vary... but I have seen results under 2 >different types of configurations. > >Another possibility that has been suggested as to why some machines die is >that the machine's route table is being blown up by the spoofed >packets. Each spoofed packet has a different source address which means >that a temporary route table entry is being created for each one. These >entries take time to timeout. Use 'vmstat -m' and check the 'routetbl' >field while the attack is going on. > >Route table entries can be controlled somewhat under freebsd with: > >[root@solid]::[~] sysctl -a | fgrep .rt >net.inet.ip.rtexpire: 3600 >net.inet.ip.rtminexpire: 10 >net.inet.ip.rtmaxcache: 128 > >You can do the following, to help if the route table is at least part of >the problem: > >sysctl -w net.inet.ip.rtexpire=2 >sysctl -w net.inet.ip.rtminexpire=2 > >Things that will help: > >1 -- drop all multicast packets (ingress and egress) that are addressed to >the tcp stack because multicasts are not valid for tcp >2 -- extend bandwidth limiting to include RST's, ACK's and anything else >that you feel could affect the stability of the machine. >3 -- dont look for listening sockets if the packet is not a syn > >I hope that this helps, or explains a little more at least. > >----------------------- >:: conclusion >----------------------- > >This bug was found in testing. It seems a bit more lethal than the >previous and should be addressed as such. Patches should be available now, >but I do not follow all the platforms. > >-------------------- >:: references >-------------------- > >This was done independantly, although some of the analysis and reverse >engineering of concept was done by other people. As a result, I would like >to give credit where credit is due. The following people contributed in >some way or another: > >Brett Glass >Alfred Perlstein >Warner Losh >Darren Reed >Don Lewis > >Also, I would like to send shouts out to w00w00 (http://www.w00w00.org/) > >------------------- >:: attached >------------------- >These programs are for the sake of full disclosure, don't abuse >them. Spank was written with libnet, so you will need to obtain that as well. > >for an "unofficial" patch: >http://solid.ncsa.uiuc.edu/~liquid/patch/don_lewis_tcp.diff > >for spank.c: >http://solid.ncsa.uiuc.edu/~liquid/code/spank.c > >NOTE: These are just temp locations. They will not be there forever and I >reserve the right to remove them at anytime. > >/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/ >+-------- ------- ------ ----- ---- --- -- ------ --------+ -- 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