netbsd.arp.table.txt

`-----BEGIN PGP SIGNED MESSAGE-----  
  
NetBSD Security Advisory 1999-010  
=================================  
  
Topic: ARP table vulnerability  
Version: NetBSD-1.3*  
Severity: Denial of service or traffic hijacking from local network  
cable is possible  
  
  
Abstract  
========  
  
The implementation of ARP packet reception is vulnerable two attacks:  
  
- on multihomed hosts, ARP packets from cable A can overwrite  
ARP entries for cable B.  
  
- for all hosts, ARP packets can overwrite ARP entries marked  
as static.  
  
  
Technical Details  
=================  
  
ARP is a protocol used to dynamically obtain IPv4 to Link level address  
translation, used for Ethernet, FDDI, Token ring, and ARCnet cables,  
described in RFC 826.  
  
The first vulnerability is specific to hosts with more than one ARP capable  
network attached. The address information of incoming ARP packets is not  
checked to ensure that it corresponds to one of the addresses of the  
interface on which the packet arrived. Thus, it would be able to suppress  
or redirect traffic from the attacked host to a different destination.  
  
The second vulnerability is related to so-called "static" arp entries.  
The original NetBSD ARP implementation (as that of most other vendors)  
allows the creation of "static" or "permanent" ARP entries. They are  
typically used for two reasons:  
  
- as a security measure, to disallow the redirection of traffic  
addressed to priviledged hosts by rogue hosts on the cable to  
themselves or elsewhere,  
  
- as a cheap routing protocol ("proxy ARP"), mostly when  
connecting single hosts through point to point links. To the  
outside, they occur as if they where on the (e.g.) Ethernet, but  
traffic destined for them is redirected by the ARP mechanism to  
the routing host.  
  
The 2nd usage doesn't create specific denial of service possibilities as  
the ARP protocol is insecure in itself.  
  
However, if static ARP entries are used to prevent D.O.S. attacks, they need  
to be protected from overwriting.  
  
  
Solutions and Workarounds  
=========================  
  
NetBSD-1.4, and NetBSD-1.4_BETA after 1999-05-05, are fixed.  
  
A patch is available for NetBSD 1.3.3 to fix this problem. You may  
find this patch on the NetBSD ftp server:  
  
ftp://ftp.NetBSD.ORG/pub/NetBSD/misc/security/patches/19990505-arp  
  
  
NetBSD-current since 19990506 is not vulnerable. Users of  
NetBSD-current should upgrade to a source tree later than 19990506.  
  
  
  
Thanks To  
=========  
  
Both vulnerabilities were reported by Olaf "Rhialto" Seibert in NetBSD  
PR 7489 and PR 7490. A fix was provided by Zdenek Salvet in PR 7497,  
and integrated into NetBSD by Ignatios Souvatzis.  
  
  
Revision History  
================  
  
1999/05/21 - initial version  
  
  
More Information  
================  
  
Information about NetBSD and NetBSD security can be found at  
http://www.NetBSD.ORG/ and http://www.NetBSD.ORG/Security/.  
  
  
Copyright 1999, The NetBSD Foundation, Inc. All Rights Reserved.  
  
$NetBSD: NetBSD-SA1999-010.txt,v 1.3 1999/05/21 12:47:00 mrg Exp $  
  
-----BEGIN PGP SIGNATURE-----  
Version: 2.6.3ia  
Charset: noconv  
  
iQCVAwUBN0VV2j5Ru2/4N2IFAQHDLwQAht39y0fw6s9lve+8L+LDaH5LPDHXkj3X  
YlPtGQAmqKOy/qf8sRbnHYQOm4uxmLpUv5KJznL37o5C8PvA/YZSU5Yq2S7Modkk  
Po0fxKeacwwf6y4gkT3s6TNOl1W6vxg3P2Ruir6dRbC5FNS4G6PCboa4yUjA0pg2  
MSU393S0GV8=  
=b765  
-----END PGP SIGNATURE-----  
  
--------------------------------------------------------------------  
  
Re: NetBSD Security Advisory 1999-010  
  
Olaf Kirch ([email protected])  
Fri, 21 May 1999 16:59:21 +0200   
  
Talking of ARP, at least Linux has the problem that it blindly accepts  
whatever hardware address it finds in the ARP response -- be it the  
MAC broadcast address, or a multicast one. Not sure wheter other  
OSs are affected.  
  
I didn't find anything dangerous you can do with this, unless there's  
some really stupid IP stack that tries to forward IP packets that were  
sent to the MAC broadcast--that would indeed be network meltdown. But  
I haven't seen such a stack.  
  
I reported this to Alan a week or two ago, so I would assume that  
it has been fixed in the meanwhile :)  
  
Olaf  
--  
Olaf Kirch | --- o --- Nous sommes du soleil we love when we play  
[email protected] | / | \ sol.dhoop.naytheet.ah kin.ir.samse.qurax  
  
--------------------------------------------------------------------  
  
Re: NetBSD Security Advisory 1999-010  
  
Ryan Russell ([email protected])  
Sun, 23 May 1999 12:27:47 -0700   
  
>Talking of ARP, at least Linux has the problem that it blindly accepts  
>whatever hardware address it finds in the ARP response -- be it the  
>MAC broadcast address, or a multicast one. Not sure wheter other  
>OSs are affected.  
>  
>I didn't find anything dangerous you can do with this, unless there's  
>some really stupid IP stack that tries to forward IP packets that were  
>sent to the MAC broadcast--that would indeed be network meltdown. But  
>I haven't seen such a stack.  
  
I'm not sure exactly what you mean by "forward" in this case... whether  
you mean forward in the router sense, or whether you mean forward up  
the IP stack inside the box..  
  
In both cases.. I don't think it matters. Nearly all IP stacks will accept  
frames sent to a broadcast MAC address. That's how broadcast  
pings work. If a Linux box can be tricked to think an IP address  
maps to the broadcast MAC address via ARP tricks, that could  
be really useful in a switched environment. Doesn't break anything, either,  
until the network melts down with broadcasts.  
  
Ryan  
  
--------------------------------------------------------------------  
  
Re: NetBSD Security Advisory 1999-010  
  
Ryan Russell ([email protected])  
Mon, 24 May 1999 09:27:11 -0700   
  
  
  
>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.  
  
--------------------------------------------------------------------  
  
Date: Tue, 25 May 1999 20:42:22 +1200  
From: Russell Street <[email protected]>  
To: [email protected]  
Subject: Re: NetBSD Security Advisory 1999-010  
  
I recently researched this and could find any reference in the RFCs or  
common TCP/IP books on using multicast addresses in ARP replies. The  
ARP RFC (RFC826) does not say one way or the other.  
  
  
  
> 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.  
  
One thing that can be configured to use multicast Ethernet addresses  
for unicast IP addresses is Microsoft's WLBS (Windows Load Balancing  
Server/Service).  
  
  
Briefly:  
  
- a set of machines appear to have a single IP address and the  
machines somehow load balance incoming requests  
  
It does this by  
  
- when the cluster's IP address is ARP'd for the cluster responds with  
a made up MAC address  
  
- all the machines participating in the cluster are expected to see  
the packets to the cluster MAC address and then agree among themselves  
who is handling it  
  
- the response (TCP ACK or whatever) comes out with a different MAC  
address from one cluster member.  
  
  
It relies on all cluster hosts seeing the inbound packets. Works  
wonderfully on a hub. If the cluster hosts are connected to a switch  
it requires the switch to flood the unknown cluster MAC address to all  
ports. This will happen because the MAC address in the ARP reply  
never appears as a source address.  
  
Some older switches will only flood to a backbone port, so this does  
not work at all.  
  
Clever switches have flood limits that choke it off, viewing it as  
broadcast storm that needs to be controlled. So WLBS works until the  
traffic load goes high enough to kick in flood limits.  
  
  
  
WLBS lets you use a multicast Ethernet address for the cluster MAC  
address. Presumably so you could configure a modern Ethernet switches  
to send that multicast to minimal set of ports. More likely as a  
gross hack around limits of some switches ;) This is off by default  
because some routers do not like it; the help file does not say which ones.  
  
  
  
  
Russell  
  
  
(The people who installed this onto our network only discovered all  
this after the network team read the help file to them... over shouts  
of "this network stinks" and "we need more bandwidth!")  
  
--------------------------------------------------------------------  
  
Date: Tue, 25 May 1999 14:22:48 -0400  
From: der Mouse <[email protected]>  
To: [email protected]  
Subject: Re: NetBSD Security Advisory 1999-010  
  
>> 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.  
  
My opinion is that they shouldn't stop you from doing stupid things  
when that also stops you from doing clever things.  
  
> One thing that can be configured to use multicast Ethernet addresses  
> for unicast IP addresses is Microsoft's WLBS (Windows Load Balancing  
> Server/Service).  
  
Auspex has a product that does likewise; ServerGuard, I think they call  
it. It too will break (or be broken by, depending on your point of  
view) any box that doesn't accept multicast MAC addresses in ARP  
replies. (At least if what I retain of what I read of the ServerGuard  
docs way back when is correct. We've never used ServerGuard, but when  
I saw the description I was puzzled enough to ask the Auspex techies  
how it could possibly work....)  
  
It might be nice to have knobs so that the sysadmin can disable  
acceptance of multicast and broadcast MAC addresses in ARP replies. I  
would call it broken to refuse them without providing a knob for the  
sysadmin to change that behavior.  
  
der Mouse  
  
[email protected]  
7D C8 61 52 5D E7 2D 39 4E F1 31 3E E8 B3 27 4B  
  
--------------------------------------------------------------------  
  
Date: Tue, 25 May 1999 12:25:45 -0700  
From: Mike Oliver <[email protected]>  
To: [email protected]  
Subject: Re: NetBSD Security Advisory 1999-010  
  
Russell Street <[email protected]> wrote:  
> I recently researched this and could find any reference in the RFCs or  
> common TCP/IP books on using multicast addresses in ARP replies. The  
> ARP RFC (RFC826) does not say one way or the other.  
  
RFC 1812, the "Router Requirements" RFC, says in section 3.3.2:  
  
A router MUST not believe any ARP reply that claims that the Link  
Layer address of another host or router is a broadcast or multicast  
address.  
  
That RFC was published in June 1995. A lot of implementations  
before that time were happy to accept multicast MAC addresses.  
I know this because ...  
  
> > 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.  
>  
> One thing that can be configured to use multicast Ethernet addresses  
> for unicast IP addresses is Microsoft's WLBS (Windows Load Balancing  
> Server/Service).  
  
... in a prior life (ie before I came to Sun) we used an  
IP-to-multicast-MAC mapping in a server cluster project, not for load  
balancing but for failover. At any given time only one of the cluster  
nodes would have an active IP address above the multicast MAC address,  
but if that node failed then some other node would activate the IP  
address over the same MAC multicast address. Voila, IP failover with  
no need to worry about refreshing anyone's ARP cache.  
  
At the time (1993?) this worked against all major router vendors except  
for, I think, Bay Networks' gear. However, it always felt like a  
kludge and eventually we eventually dropped it in favour of a scheme  
that sent unsolicited broadcast ARP responses advertising a unicast MAC  
address when this kind of failover occurred.  
  
Mike.  
--  
[email protected]  
  
`