Re: udp packet storms

[dawagner () phoenix Princeton EDU (David A. Wagner)]

> > The RFCs specify that you must never respond to an ICMP request with a
> > broadcast. However, this may work with UDP echo ports on hosts with
> > defective behavior of the sort we've just been noting.
>
> When doing broadcast pings (for network debugging), I've regularly
> noticed a number of the, umm, less-than-solid IP stacks make this mistake.
> If a network is half Suns and half PCs, the PCs often respond with a source
> broadcast address.
>
> I'm sure they're doing this because the ICMP ECHO code simply swaps the
> source and destination addresses, sets the ICMP type, and returns the
> packet.
>
> As someone else pointed out though, with ICMP ECHO (ping), you won't
> get storms because the return packet is an ICMP ECHOREQUEST, a completely
> different type of packet.

Hrmm.  We have a special version of ping installed here, but
the command

        ping -eraw 255.255.255.255

will consistently and reliably panic any Sun here.

[I haven't tried it for any other OS, as our computer center
probably wouldn't look kindly at me crashing all our hosts. :-]

> From the man page on our ping (not Sun's default /usr/etc/ping):

     -e   This option causes the  pinger  to  send  Echo  Replies
          rather  than Echo Requests. It is useful for pinging an
          "echo pseudo-host" which does no ICMP  Echo  processing
          but  simply  swaps  IP source and destination addresses
          and returns the packet.

     -eraw
          This option, like -e, is intended for use with an  echo
          pseudo-host.  The -eraw option will cause the packet to
          be sent with  an  IP  header  that  specifies  protocol
          number 255 rather than the ICMP protocol.  This is use-
          ful for diagnosing a path to an echo host which is mak-
          ing  bit errors. While the SUN kernel will throw away a
          returned packet with a bad ICMP  checksum,  a  protocol
          255 packet will be passed up to  ping regardless of bit
          errors in the packet (although a damaged IP header will
          still  cause  the packet to be discarded). In addition,
          datalen-8 bytes of each packet are checked for  corrup-
          tion,  and the byte offset and hexadecimal value of any
          bit difference is displayed.

I wish I had a sniffer to see exactly what is happening, but
presumably the Sun sends out a broadcast packet, gets deluded
with a huge number of responses, and then there must be some
bug in the SunOS 4.1.3_U1 kernel which panics the machine?

I haven't been able to duplicate this with the standard SunOS
/usr/etc/ping (the one which prints messages like "x is alive").

Our copy of ping is installed setuid root; the source is
available for anonymous FTP from princeton.edu under the
filename /pub/ping.tar.Z.  When I say "our" ping, I don't
mean that it was developed here (at least I don't think it
was) -- I just mean that it is installed here.  Read the
source for credits as to who wrote it...

So, even if you don't have this ping installed at your site,
presumably a bad guy could inject one of these "protocol 255
echo reply broadcast packets" onto your network, right?

Would anyone with a sniffer be interested in investigating
this?  If you forge one of these packets, will it pass through
routers?  Does it happen with other operating systems?  Why
does it crash the system?  Are there any patches?

-------------------------------------------------------------------------------
David Wagner                                             dawagner () princeton edu