-----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 (okir@MONAD.SWB.DE) 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 okir@monad.swb.de | / | \ sol.dhoop.naytheet.ah kin.ir.samse.qurax -------------------------------------------------------------------- Re: NetBSD Security Advisory 1999-010 Ryan Russell (Ryan.Russell@SYBASE.COM) 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 (Ryan.Russell@SYBASE.COM) 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 To: BUGTRAQ@netspace.org 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 To: BUGTRAQ@netspace.org 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 mouse@rodents.montreal.qc.ca 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 To: BUGTRAQ@netspace.org Subject: Re: NetBSD Security Advisory 1999-010 Russell Street 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. -- mike.oliver@eng.sun.com