From owner-freebsd-net@FreeBSD.ORG Fri Jul 9 18:10:11 2010 Return-Path: Delivered-To: freebsd-net@hub.freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 18F231065674 for ; Fri, 9 Jul 2010 18:10:11 +0000 (UTC) (envelope-from gnats@FreeBSD.org) Received: from freefall.freebsd.org (freefall.freebsd.org [IPv6:2001:4f8:fff6::28]) by mx1.freebsd.org (Postfix) with ESMTP id E2DBD8FC1A for ; Fri, 9 Jul 2010 18:10:10 +0000 (UTC) Received: from freefall.freebsd.org (localhost [127.0.0.1]) by freefall.freebsd.org (8.14.4/8.14.4) with ESMTP id o69IAA1l042125 for ; Fri, 9 Jul 2010 18:10:10 GMT (envelope-from gnats@freefall.freebsd.org) Received: (from gnats@localhost) by freefall.freebsd.org (8.14.4/8.14.4/Submit) id o69IAAUG042124; Fri, 9 Jul 2010 18:10:10 GMT (envelope-from gnats) Date: Fri, 9 Jul 2010 18:10:10 GMT Message-Id: <201007091810.o69IAAUG042124@freefall.freebsd.org> To: freebsd-net@FreeBSD.org From: Paul Miseiko Cc: Subject: Re: misc/148463: [arp] ARP cache can be poisoned or polluted with ease. X-BeenThere: freebsd-net@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list Reply-To: Paul Miseiko List-Id: Networking and TCP/IP with FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 09 Jul 2010 18:10:11 -0000 The following reply was made to PR misc/148463; it has been noted by GNATS. From: Paul Miseiko To: "bug-followup@FreeBSD.org" , "pmiseiko@gmail.com" Cc: Subject: Re: misc/148463: [arp] ARP cache can be poisoned or polluted with ease. Date: Fri, 9 Jul 2010 10:45:17 -0700 --_000_3B704C911550A340BE8731F1331016D50300E87E92exchange01tor_ Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable You are right that a static ARP entry would resolve the cache poison issue = and that the suggested solution might be more complicated then desired to m= itigate (only) some of the risk associated with the cache poison issue. What about the ARP cache pollution issue? The description described two po= tential issues with how FreeBSD implemented the ARP cache. The first issue= is that FreeBSD has no risk mitigation for an ARP cache poison attack (oth= er than the acknowledged static ARP entries). The second issue is that Fre= eBSD will create ARP cache entries when FreeBSD has not issued an ARP reque= st. The second issue might overlap with the comment you made here "if I ch= ange some hardware for example I can force update the ARP entry by connecti= ng to the box that needs to be updated" but it is a valid security concern = on an un-trusted network and FreeBSD has no risk mitigation for this issue = (that I am aware of at this time). It would be helpful to see at the very = least a configuration option (sysctl) to mitigate the risk associated with = the ARP cache pollution scenario. --_000_3B704C911550A340BE8731F1331016D50300E87E92exchange01tor_ Content-Type: text/html; charset="us-ascii" Content-Transfer-Encoding: quoted-printable

You are right that a static ARP entry would resolve th= e cache poison issue and that the suggested solution might be more complicate= d then desired to mitigate (only) some of the risk associated with the cache poison issue.

 

What about the ARP cache pollution issue?  The description described two potential issues with how FreeBSD implemented the= ARP cache.  The first issue is that FreeBSD has no risk mitigation for an = ARP cache poison attack (other than the acknowledged static ARP entries). = The second issue is that FreeBSD will create ARP cache entries when FreeBSD has= not issued an ARP request.  The second issue might overlap with the commen= t you made here “if I change some hardware for example I can force upda= te the ARP entry by connecting to the box that needs to be updated” but = it is a valid security concern on an un-trusted network and FreeBSD has no ris= k mitigation for this issue (that I am aware of at this time).  It would= be helpful to see at the very least a configuration option (sysctl) to mitigat= e the risk associated with the ARP cache pollution scenario.

--_000_3B704C911550A340BE8731F1331016D50300E87E92exchange01tor_--