Re: explanation and code for stream.c issues

[yardley () UIUC EDU (Tim Yardley)]

> > 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/
+--------  -------  ------  -----  ---- --- -- ------ --------+