Date: Tue, 25 Jan 2000 15:15:16 -0600 From: Tim Yardley <yardley@uiuc.edu> To: freebsd-security@FreeBSD.ORG Subject: Fwd: multicasts from hell Message-ID: <4.2.0.58.20000125151430.01234f10@students.uiuc.edu>
next in thread | raw e-mail | index | archive | help
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 <yardley@UIUC.EDU>
>Sender: Bugtraq List <BUGTRAQ@SECURITYFOCUS.COM>
>From: Tim Yardley <yardley@UIUC.EDU>
>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 <brett@lariat.org>
>Alfred Perlstein <bright@wintelcom.net>
>Warner Losh <imp@village.org>
>Darren Reed <avalon@coombs.anu.edu.au>
>Don Lewis <Don.Lewis@tsc.tdk.com>
>
>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
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?4.2.0.58.20000125151430.01234f10>