Vulnerability Development mailing list archives
Re: ARP silliness w/ Cisco 675
From: mikael.olsson () ENTERNET SE (Mikael Olsson)
Date: Wed, 29 Sep 1999 11:19:30 +0200
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 signedThis 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 matchThis 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
Current thread:
- Re: ARP silliness w/ Cisco 675 Mikael Olsson (Sep 28)
- Re: ARP silliness w/ Cisco 675 Trevor Schroeder (Sep 28)
- Re: ARP silliness w/ Cisco 675 Mikael Olsson (Sep 29)
- Re: ARP silliness w/ Cisco 675 Trevor Schroeder (Sep 29)
- Re: ARP silliness w/ Cisco 675 Mikael Olsson (Sep 29)
- Re: ARP silliness w/ Cisco 675 Trevor Schroeder (Sep 28)
- Re: ARP silliness w/ Cisco 675 Trevor Schroeder (Sep 28)