Fwd: UDP packet handling weird behaviour of various operating systems

David Klasinc bigwhale at m42.cx
Fri Jul 27 14:32:07 CEST 2001


Banzai!

 Nekaj dni nazaj na BugTraq...

Zanimivo. :)

----------  Forwarded Message  ----------
Subject: UDP packet handling weird behaviour of various operating systems
Date: Tue, 24 Jul 2001 23:36:39 +0300
From: Stefan Laudat <stefan at mail.allianztiriac.ro>
To: bugtraq at securityfocus.com


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

-------------------------------------------------------

David!
---------------
I want to die peacefully, in my sleep, like my grandfather, not screaming,
terrified, like his passengers.



More information about the lugos-sec mailing list