> Hi !
> I've noticed that inetd doesn't check the source port for the request
> to UDP simple services (echo, time, chargen, daytime).
> This means it is possible to build a packet which will look like it comes
> from one of these ports, to one of these ports. In this case, each UDP
> response from the simple service will generate a new request to the source
> port and the system or network can be quickly overloaded.
Hate to break this to ya but this is OLD news. A lot of us have
been refering to this as the "network food fight". Try this - spoof the
UDP packet to a the chargen port on a system with the src address spoofed
to be the echo port on the BROADCAST address for that subnet. Picture the
result. :-) Do that a few times and see what your bandwidth looks like!
This is why the monicure of "food fight".
AFAIK... You can't use this trick to generate a true "classical"
"broadcast storm" (those of you who remember the bad old days of the food
fight's between VAX's and SunOs 3.2/3.5 [Da NOS from HELL!] know what I'm
talking about here... :-) ) but you can come damn close. I don't know of
anyway to perpetuate the broadcast address beyond the first generation. The
responder always responds with his unicast address so the broadcast storm goes
linear after one generation and settles into a pong game, as you describe,
on steroids. Unlike a true "broacast storm", where the packets go geometric
after the one trigger, you would need to keep stoking this until the network
is so clogged that the difference between this and a broadcast storm would
be academic at best.
> to test this, I've written a program, let's say an exploit... It completely
> builds an UDP packet from RAW IP.
Or use any one of a number of commonly available security testing
tools.
Excuse the product plug here - but Internet Security System's
Internet Scanner has been checking for this for over 6 months.
> You just have to specify which IP and PORT you want for source and
> destination, and then look at the result.
>
> On my Linux 2.0.29, inetd goes to 99% CPU when source/dest are the same
> machine with any of these 4 ports.
>
> I tested Netware Client 32 for DOS/Windows, and it simply hangs. Not tested
> yet on Win95/NT/Netware...
>
> Concerning Linux, I've patched inetd to prevent it from replying to
> requests coming from a port below one specified in the source (I chose 128).
We recommend the following:
1) If you don't need chargen and echo (or daytime, etc) TURN THEM OFF!
I know of only one case where these services are used for anything, and that
is an obscure remote boot network device senario. If you don't need it,
don't do it! Especially UDP!
2) Echo, and chargen, and daytime, etc, etc, etc, should not accept
packets from any of the WKS (Well Known Service) ports which means anything
below port 2048.
> Here comes the exploit, and next, the patch for inetd (inetd from
> NetKit-0.09).
>
>
> Willy Tarreau
> --
> +---------------+------------------------+--------------------------------+
> | Willy Tarreau | tarreau@aemiaif.ibp.fr | http://www-miaif.ibp.fr/willy/ |
> | Magistere d'Informatique Appliquee de l'Ile de France (MIAIF), promo 97 |
> | DEA A.S.I.M.E. | Universite Pierre et Marie Curie (Paris 6), FRANCE |
> +-----------------+-------------------------------------------------------+
Mike
-- Michael H. Warfield | (770) 985-6132 | mhw@WittsEnd.com (The Mad Wizard) | (770) 925-8248 | http://www.wittsend.com/mhw/ NIC whois: MHW9 | An optimist believes we live in the best of all PGP Key: 0xDF1DD471 | possible worlds. A pessimist is sure of it!