Re: ARP silliness w/ Cisco 675

[mikael.olsson () ENTERNET SE (Mikael Olsson)]

Trevor Schroeder wrote:
> On Tue, 28 Sep 1999, Mikael Olsson wrote:
>
> > The ARP RFC states that when a host receives an ARP
> > query for itself, it should enter the sender's
> > address tuple into its ARP table so as to refrain
> > from having to query for information that it has
> > already, in effect, received.
>
> Just because the RFC states it, does not make it gospel.  As much as I am
> in favor of RFC compliant behaviour, sometimes it's necessary to bend them
> as circumstances change.  Not accepting ARPs any time from any body might
> be an acceptable change.  It's not something that breaks the operation of
> the protocol.

The main reason I pointed this out is that this is what people do
in general; hence, it is usually real easy to spoof an ARP, even
though there's a race condition protection in place for the
responses.
(vuln-dev, remember :-)

However, when you don't have an entry for that host, you have
to make a decision:
1. Accept the address
2. Query for the address and see if you get multiple responses

It is often the case the you do NOT have the ARP entry for
a specific host; either due to reboot of either unit or due
to no communication between the units for some time.

(Yeah yeah the reboot problem is not such a great problem
with linux hosts and cisco routers, I know. Too bad a lot of
people have a lot less stable (a-hem) OSes running.)

> > [Requerying addresses every time you get a question]
> That's icky.

But it's the only protection you'll ever have if you don't already
have an entry.

> > 1. Add a central system having a master list
> > of MAC/IP tuples, which sends responses signed
>
> This is a really Bad Idea [tm].  You should consider long and hard before
> you resort to a central coordinator (and point of failure).  That's the
> whole point behind having a distributed algorithm such as ARP.

I think I pointed out in my original post that these ideas were
"far from finished concepts" or something like that.
I just threw them out to give people some rough ideas that could
be used for further ideas, rather than for having them stomped at.

I know this isn't very practical. I maybe should have pointed
it out more feriouciosly.

> Besides, how are we going to know the ARP server's MAC address?
>
> > by an asymmetric cipher function. (Certificate)
>
> Now this is the correct approach but in the wrong context.  The proper
> solution is IPsec's authentication headers.  Let layer 2 play games if you
> want, but your attacker is going to have a hard time getting the AH right.

A-ha! Who was the first? The chicken or the egg?
You can't have IPSec work if your layer 2 doesn't work.
IPSec prevents sniffing and impersonation (using both AH and ESP as
you pointed out later on), but it does NOT prevent DoSing the
poor bastards with wild ARP spoofing.

> > 3. When you receive a changed MAC address, query
> > for the IP again and see what responses you receive
> > in, say, 1 second. If any of the responses match
>
> This is sort of what Linux does.  Not strictly RFC compliant, but close
> enough for government work.  (actually it checks the old MAC to see if it
> still claims the IP address being queried)

Here is where it gets interesting, things like these can be implemented
without totally rewriting the ARP protocol.

I have to wonder though, when you say "checks the old MAC to see if
it still claims the IP", do you mean that it sends out a directed ARP
to the old MAC, asking for the IP? Or does it broadcast?

In either case, I believe there are at least five ways that this
algorithm could be defeated (NOTE: A careful coder can protect
against 1 and 2)

1. Intruder races for the response, which says "No MAC Addr". This
   is compliant with RFC 1868, "UNARP". The response basically has
   HWAddrLen=0.
2. Intruder races for the response, which says that the hw addr for
   the IP is the hw addr of the intruder.

Again, no flames for 1 and 2, these would only be a problem
if the coder screwed up. (But they DO screw up >:] )

3. Intruder floods the network of either host to the point where
   either the query to the old host or the response from it gets
   blocked. Remember that the intruder doesn't have to flood the
   network for very long, and that this attack doesn't have to
   work the first time.
   A half-ass protection scheme would be to keep resending the
   queries to the old host for a very long time.
   I can see that kind of behaviour leading to serious stress
   syndromes if an intruder starts trying to spoof a lot of ARPs.
4. Crash the original host, or make it consume lots and lots of CPU
   power for a while. This way, it won't respond to the safety query.
5. Crash the original host and wait for the ARP entry pointing
   to it to die from itself. This could be circumvented
   if all ARP entries never timed out. Again, this might lead
   to really nasty overload situations; sooner or later
   one would probably have to start throwing ARP entries away
   to preserve memory. This is especially the case in a
   10.0.0.0/8 flat switched network.

Also, a real problem with these "sticky" ARPs is that once an
intruder gets hold of an IP address, it'll actually work
to his/her advantage.

*phew*
I suppose I could think of a few more if I really put my
mind to it.


--
Mikael Olsson, EnterNet Sweden AB, Box 393, S-891 28 ÖRNSKÖLDSVIK
Phone: +46-(0)660-105 50           Fax: +46-(0)660-122 50
WWW: http://www.enternet.se        E-mail: mikael.olsson () enternet se