UDP packet handling weird behaviour of various operating systems

[Stefan Laudat <stefan () mail allianztiriac ro>]

Hi Aleph,
Sent this already to you a couple of months ago but I presume it got
sucked into a quasar on its way to you.Maybe it gets lucky this time.           


Looks like there are some problems in some of the most popular TCP/IP 
stack implementations. I've found a kiddie-tool on the internet that
looks like it's rising some problems in a matter of CPU usage for handling
incoming UDP packets. Its initial aim was another one (read the source)
but accidentally it can be used for locking up machines.
You can try it from
http://rootshell.com/archive-j457nxiqi3gq59dv/199803/biffit.c

I'm not a TCP stack-writing guru but I presume the behaviour described below
is way beyond normal, as its results are quite different depending on the
OS used. Please don't bash me if I'm wrong.

Here are the reactions of major OS'es on the market on this simple UDP flood.
Be aware that the results are working on the quoted kernels no matter if
their specific ip-filtering mechanisms have UDP filtering rules enabled or not
and no matter if you really have in.comsat running or not, you may change
the destination port to whatever and get the same result:

1. Linux 2.4.7 UP (pristine source, waiting for a new shiny Alan Cox patch) 
        - system gets frozen after 3 seconds of flood on a gigabit link.
Same result at a 100Mbps. The top utility shows (at least as long as it can)
that system(kernel) gets 100% of the CPU in its march to death. Same for
Linux kernel 2.2.19.

2. Linux 2.4.7 SMP (same origin)
        - the flood effect is distributed on the 2 CPUs (p3/1Ghz)
at a ratio of 30-40% per processor. Linux SMP is superb, it implements
load-sharing of everything, even DoS :)

3. Windows 2000 Server UP.
        - the system graphs jump from 2% cpu usage (in a calm evening with
no ongoing backups and domain synchronizations) to approx. 35% and holds
it steady. The flood is performed via a Gigabit link. The packet rate
handling of win2k is wonderful, it even beats an OpenBSD 2.8. Kudos to
MS guys, this one is a real hit. As I couldn't believe my eyes I ran some
applications on it (crunching queries on the local MS SQL2k server etc) and I
got timely-fashion responses.

4. Open BSD 2.8 UP, no patches applied
        - top utility shows a 45% processor load and holds it steady.
The system is responsive (unlike Linux) and the apps are running okay.

5. Windows 2000 Professional UP.
        - systems gets an extra 60% load average payload over its
initial one. It is still responsive to commands, doesn't choke a bit.

6. Windows ME UP
        - this little bitch runs OpenGL apps under heavy UDP hammering
with no CPU cost ! Like nothing happened. Heilz to MS again.

7. Cisco IOS
        - tested on Cisco 7513 (12.1(4)E, DCEF enabled), Cisco 2621 (12.2.1),
Cisco Catalyst 35xxXL (12.0.5.2.XU and 12.0.5.1.XP). I'm walking here on Linux-behaviour
land. The CPU is burning at high load averages from the start and I get no control
over it. I can get the result either directly attacking the router, either forwarding 
for a host behind it. IOS plays the brave guy and gets it for anyone else too.

8. SunOS 5.7 running on an UltraEnterprise 3500
        - beautiful reaction. No CPU waving on this SMP system, looks like nothing
happened to it. I'll buy one for home when I'll be a millionaire :)


I would like to hear some other results for other operating systems.

Greetz go as usual to Gore, my old one-eye pirate parrot and to his fat wife that ruined
his long glorious life.


P.S. [offtopic] can someone please write a detailed mail here to explain how easily
is to defend/log CodeRed with Snort and FlexResp support? It would have been the
only practical thing discussed about it among tons of repetitive and identical advisories
of 'security experts' that solve nothing so far. I block hundreds of worms daily this way
without having a patched IIS. My recent post regarding this was blocked already because the
thread was (err...) "ended" by fate or whatever so it wasn't relevant or even read.

-- 
Stefan Laudat
CCNA,CCAI
Senior Network Engineer
Allianz-Tiriac SA

"Let's call it an accidental feature."
        -- Larry Wall