>No. I was thinking of forward in the router sense. Assume network 10.0.0.0
>with router 10.0.0.1, and a box A on that network which responds to
>every ARP query for address 10.0.0.1 with the MAC bcast addr. Send a
>packet addressed to 1.2.3.4 to the mac bcast address.
If some host manages to trick other hosts on it's net into thinking that
the router, 10.0.0.1, is MAC address ff:ff:ff:ff:ff:ff, then all hosts will
get the packets from the hosts that have been tricked, for packets
that were supposed to be for the router. This includes the router,
so it will still work. Other hosts will get it at layer 2, and drop it at layer
3,
unless they are also routers (see below). This, of course, gives everyone
a chance to sniff that traffic, even on a switch.
>Hypothetical IP stack receives packet, decides to forward it to router
>(also sends ICMP redir). ARPs for router, receives bcast addr from box A.
>Cycle repeats until IP TTL goes through zero.
If there is only one host on the subnet (the router) that performs an IP
forward function, all is well... we just have more broadcast traffic. If there
are two more hosts that perform IP forwarding... there could be big trouble,
if they've been fooled by the ARP trick as well. For example, Solaris
boxes will attempt to IP forward even if they have a single interface. This
"feature" has to be explicitly turned off each boot with NDD, or the kernel
modified. So, any of these Solaris boxes who get the broadcast packet
will do as you say, try to send it to the real router, and send the ICMP
redirect. They won't receive their own broadcast, so that's why you
need two of them to get the bounce effect.
So, this means you'll get TTL*(number of IP forwarders who aren't real router)
copies of each packet... which could be a lot.
>All boxes send an ICMP
>time exceeded message to the sender. If the sender is also non-local, the
>game continues.
Yes. If it's local, it simply sends unicasts... but you're right, if it's
off-net,
continue... Perhaps fortunately, by default Solaris machines will limit
how often they send ICMP unreachables... again, adjustable with
NDD or kernel mods.
>However, I've not seen such a network stack. That's why I posted the
>thing to bugtraq.
I still think I've seen "such a network stack" for all the cases mentioned..
Now, I don't know if Solaris boxes will accept multicast addresses as
an ARPed for address or not. I also don't know if other boxes (specifcially,
the Linux and NetBSD boxes who DO get fooled by bad ARP addresses)
will IP forward by default even if they have only one interface. It would be
useful to know... I won't have the time to do the tests myself for a few days,
and I suspect someone will pipe up before I can get to it.
My personal opinion is that ARP should be fixed on all IP stacks (well..
ARP "stack") so that they won't accept multicasts addresses.. I can't
think of any reason why they should. (For those who don't know...
whether an address is multicast or not is controlled by a single
bit.. it's just an AND and a EQUAL check... pretty cheap in terms of
processing)
And while I'm at it... it may be a good idea to shut of the IP forwarding
feature of machines you don't actually want to route... having this on
makes certain ARP redirection/sniffing games that much easier. Again,
I think that if those machines aren't actually routing anything, this breaks
nothing.
Ryan
P.S. Olaf, I hope you don't mind that I added Bugtraq back to the
CC list, even though you took it off. I'm not trying to publicize
anything you intended to keep private.. I just think the Bugtraq
readers might be interested.
This archive was generated by hypermail 2b30 : Fri Apr 13 2001 - 14:46:41 PDT