misc/148463: [arp] ARP cache can be poisoned or polluted with ease.

[Gleb Kurtsou]

On (09/07/2010 18:10), Paul Miseiko wrote:
> The following reply was made to PR misc/148463; it has been noted by GNATS.
> 
> From: Paul Miseiko <Paul_Miseiko at rapid7.com>
> To: "bug-followup at FreeBSD.org" <bug-followup at FreeBSD.org>,
> 	"pmiseiko at gmail.com" <pmiseiko at 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.
In my opinion _mitigating_ such risks/attacks falls under security by
obscurity category. It's ARP that is fundamentally broken and has no
notion of security what so ever. I don't want to get into discussing
ARP specifics, I'm just saying that your proposal won't improve
situation in general, that is the question of attacker being more
sophisticated to perform attack.

Besides static ARP entries there are (were) also ARP firewalls available
for FreeBSD. Search for it in freebsd-net@ archives.

If you are using 7-STABLE or 8.0-RELEASE you can try l2filter patch, it
adds ARP filtering options to ipfw, as far as I remember it also allows
specifying list of MAC addresses for a given subnet, which may prove
useful on a router.

http://github.com/glk/l2filter
http://glebkurtsou.blogspot.com/search/label/l2filter


Thanks,
Gleb.