COMMAND
kernel
SYSTEMS AFFECTED
munices
PROBLEM
For whole picture, you should first looak at:
http://oliver.efri.hr/~crv/security/bugs/mUNIXes/krnl110.html
Tim Yardley added following. 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 presented below will block all multicast packets that
come in (and possibly out) of the tcp stack. 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 we 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.
Tim has also been asked a lot about what this "bug" affects. He
has 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).
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
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 spank.c:
http://solid.ncsa.uiuc.edu/~liquid/code/spank.c
SOLUTION
If you use ipfilter... This *MAY* help you... but the issue is
quite a bit different than the previous issue.
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
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.
block out proto tcp from any to 224.0.0.0/28
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.
$fwcmd add deny all from 224.0.0.0/28 to any via ${oif}
FreeBSD "unofficial patch" by Don Lewis:
http://solid.ncsa.uiuc.edu/~liquid/patch/don_lewis_tcp.diff
Here's the patch:
--- tcp_input.c.orig Tue Apr 20 15:09:15 1999
+++ tcp_input.c Fri Jan 21 21:53:00 2000
@@ -398,12 +398,36 @@
"Connection attempt to TCP %s:%d from
%s:%d\n",
buf, ntohs(ti->ti_dport),
inet_ntoa(ti->ti_src),
ntohs(ti->ti_sport));
- }
+ } else if (tiflags & TH_ACK) {
+ /*
+ * Alpha code in response to stream.c
+ * - Omachonu Ogali
+ */
+ char buf[4*sizeof "123"];
+
+#ifdef ICMP_BANDLIM
+ if (badport_bandlim(1) < 0)
+ goto drop;
+#endif
+
+ strcpy(buf, inet_ntoa(ti->ti_dst));
+ log(LOG_INFO,
+ "received TCP/ACK to non existant
connection: %s:%d -> %s:%d\n",
+ inet_ntoa(ti->ti_src), ntohs(ti->ti_sport),
buf,
ntohs(ti->ti_dport));
+
+ /*
+ * Drop without reset to prevent smurf-like tcp
+ * attack
+ */
+
+ goto drop;
+ } else {
#ifdef ICMP_BANDLIM
if (badport_bandlim(1) < 0)
goto drop;
#endif
goto dropwithreset;
+ }
}
tp = intotcpcb(inp);
if (tp == 0)
That code will only work if the receiving host has no daemon
listening on that port, you're better off with Alfred's patch.
http://www.freebsd.org/~alred/tcp_fix.diff