From nobody@FreeBSD.org  Fri Jul  9 06:12:56 2010
Return-Path: <nobody@FreeBSD.org>
Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34])
	by hub.freebsd.org (Postfix) with ESMTP id B6729106566B
	for <freebsd-gnats-submit@FreeBSD.org>; Fri,  9 Jul 2010 06:12:56 +0000 (UTC)
	(envelope-from nobody@FreeBSD.org)
Received: from www.freebsd.org (www.freebsd.org [IPv6:2001:4f8:fff6::21])
	by mx1.freebsd.org (Postfix) with ESMTP id 8B4DE8FC15
	for <freebsd-gnats-submit@FreeBSD.org>; Fri,  9 Jul 2010 06:12:56 +0000 (UTC)
Received: from www.freebsd.org (localhost [127.0.0.1])
	by www.freebsd.org (8.14.3/8.14.3) with ESMTP id o696CuLn055185
	for <freebsd-gnats-submit@FreeBSD.org>; Fri, 9 Jul 2010 06:12:56 GMT
	(envelope-from nobody@www.freebsd.org)
Received: (from nobody@localhost)
	by www.freebsd.org (8.14.3/8.14.3/Submit) id o696Cu4s055184;
	Fri, 9 Jul 2010 06:12:56 GMT
	(envelope-from nobody)
Message-Id: <201007090612.o696Cu4s055184@www.freebsd.org>
Date: Fri, 9 Jul 2010 06:12:56 GMT
From: Paul-Andrew Joseph Miseiko <pmiseiko@gmail.com>
To: freebsd-gnats-submit@FreeBSD.org
Subject: ARP cache can be poisoned or polluted with ease.
X-Send-Pr-Version: www-3.1
X-GNATS-Notify:

>Number:         148463
>Category:       misc
>Synopsis:       [arp] ARP cache can be poisoned or polluted with ease.
>Confidential:   no
>Severity:       non-critical
>Priority:       low
>Responsible:    freebsd-net
>State:          closed
>Quarter:        
>Keywords:       
>Date-Required:  
>Class:          sw-bug
>Submitter-Id:   current-users
>Arrival-Date:   Fri Jul 09 06:20:03 UTC 2010
>Closed-Date:    Fri Jul 09 14:36:43 UTC 2010
>Last-Modified:  Fri Jul  9 18:10:09 UTC 2010
>Originator:     Paul-Andrew Joseph Miseiko
>Release:        8.1-PRERELEASE
>Organization:
>Environment:
FreeBSD teardrop.ca 8.1-PRERELEASE FreeBSD 8.1-PRERELEASE #1: Wed Jul  7 22:18:16 EDT 2010     esoteric@teardrop.ca:/usr/obj/usr/src/sys/TEARDROP  i386
>Description:
FreeBSD will add to the kernel ARP cache the source hardware address associated with the source protocol address when an ARP request packet or ARP reply packet is received and the target protocol address is the same as the interface protocol address.

A malicious user could use this behavior to alter the hardware address associated with a particular protocol address.  FreeBSD will accept the new hardware address associated with a particular protocol address that is known in the ARP cache.

A malicious user could use this behavior to perform a denial of service against the kernel ARP cache when a FreeBSD device is bound to a large network.  FreeBSD will create a kernel ARP cache entry for each ARP request packet and ARP reply packet received.
>How-To-Repeat:
Send an ARP request packet or ARP response packet to the physical broadcast address (or physical interface address) with the target protocol address set to a FreeBSD device and the source hardware address and source protocol address set to the desired protocol address to poison in the FreeBSD device kernel ARP cache or populate the FreeBSD kernel ARP cache with excessive entries.
>Fix:
#1.
FreeBSD should not permit alteration of a kernel ARP cache entry if it has not made an explicit ARP request for the protocol address associated with the kernel ARP cache entry.  The time-to-live for a kernel ARP cache entry might need to be shortened for this to work well in heterogeneous environments.  Some of the risk involved with malicious intent to redirect a protocol address to a specific hardware address will be mitigated through this change.  To perform a malicious action with this constraint would result in a race condition for when a FreeBSD device has made an ARP request to be the first to produce the expected ARP reply.  In theory a malicious user might send several ARP replies in anticipation of an ARP request.  The FreeBSD device could detect such behavior and log a message, remove the kernel ARP cache entry due to the suspicious circumstance, or accept the least frequency ARP reply.

#2.
FreeBSD should not create a kernel ARP cache entry for a protocol address it has not made an ARP request for.  The risk of a remote malicious user triggering a potential denial of service against the kernel ARP cache would be eliminated through this change.

Note.
The suggested solution(s) above could have a sysctl option to enable them.  A FreeBSD device on a trusted network would not require protection from malicious intent through the ARP protocol.

>Release-Note:
>Audit-Trail:
Responsible-Changed-From-To: freebsd-bugs->freebsd-net 
Responsible-Changed-By: linimon 
Responsible-Changed-When: Fri Jul 9 07:42:45 UTC 2010 
Responsible-Changed-Why:  
Over to maintainer(s). 

http://www.freebsd.org/cgi/query-pr.cgi?pr=148463 
State-Changed-From-To: open->closed 
State-Changed-By: remko 
State-Changed-When: Fri Jul 9 14:36:42 UTC 2010 
State-Changed-Why:  
Hello, this is why we invented static ARP if you do not want to have the 
cache modified. Else this is a perfectly valid usage, if I change some 
hardware for example I can force update the ARP entry by connecting to 
the box that needs to be updated. If that would only happen when the box 
needs to query the device for some reason it could take a long time 
which is not desired.  Would you please be so kind to review the items 
you are submitting first before sending in a PR ? Either discuss it on 
net@ or search around at google so that you are informed about what is 
fine and what is not. Eventhough my harsh previous words, I still would 
like to thank you (again) for trying to make FReeBSD better.. 

http://www.freebsd.org/cgi/query-pr.cgi?pr=148463 

From: Paul Miseiko <Paul_Miseiko@rapid7.com>
To: "bug-followup@FreeBSD.org" <bug-followup@FreeBSD.org>,
	"pmiseiko@gmail.com" <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
 
 <html xmlns:v=3D"urn:schemas-microsoft-com:vml" xmlns:o=3D"urn:schemas-micr=
 osoft-com:office:office" xmlns:w=3D"urn:schemas-microsoft-com:office:word" =
 xmlns:m=3D"http://schemas.microsoft.com/office/2004/12/omml" xmlns=3D"http:=
 //www.w3.org/TR/REC-html40">
 
 <head>
 <meta http-equiv=3DContent-Type content=3D"text/html; charset=3Dus-ascii">
 <meta name=3DGenerator content=3D"Microsoft Word 12 (filtered medium)">
 <style>
 <!--
  /* Font Definitions */
  @font-face
 	{font-family:"Cambria Math";
 	panose-1:2 4 5 3 5 4 6 3 2 4;}
 @font-face
 	{font-family:Calibri;
 	panose-1:2 15 5 2 2 2 4 3 2 4;}
  /* Style Definitions */
  p.MsoNormal, li.MsoNormal, div.MsoNormal
 	{margin:0in;
 	margin-bottom:.0001pt;
 	font-size:11.0pt;
 	font-family:"Calibri","sans-serif";}
 a:link, span.MsoHyperlink
 	{mso-style-priority:99;
 	color:blue;
 	text-decoration:underline;}
 a:visited, span.MsoHyperlinkFollowed
 	{mso-style-priority:99;
 	color:purple;
 	text-decoration:underline;}
 span.EmailStyle17
 	{mso-style-type:personal-compose;
 	font-family:"Calibri","sans-serif";
 	color:windowtext;}
 .MsoChpDefault
 	{mso-style-type:export-only;}
 @page WordSection1
 	{size:8.5in 11.0in;
 	margin:1.0in 1.0in 1.0in 1.0in;}
 div.WordSection1
 	{page:WordSection1;}
 -->
 </style>
 <!--[if gte mso 9]><xml>
  <o:shapedefaults v:ext=3D"edit" spidmax=3D"1026" />
 </xml><![endif]--><!--[if gte mso 9]><xml>
  <o:shapelayout v:ext=3D"edit">
   <o:idmap v:ext=3D"edit" data=3D"1" />
  </o:shapelayout></xml><![endif]-->
 </head>
 
 <body lang=3DEN-US link=3Dblue vlink=3Dpurple>
 
 <div class=3DWordSection1>
 
 <p class=3DMsoNormal>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.<o:p></o:p></p>
 
 <p class=3DMsoNormal><o:p>&nbsp;</o:p></p>
 
 <p class=3DMsoNormal>What about the ARP cache pollution issue?&nbsp; The
 description described two potential issues with how FreeBSD implemented the=
  ARP
 cache.&nbsp; The first issue is that FreeBSD has no risk mitigation for an =
 ARP
 cache poison attack (other than the acknowledged static ARP entries).&nbsp;=
  The
 second issue is that FreeBSD will create ARP cache entries when FreeBSD has=
  not
 issued an ARP request.&nbsp; The second issue might overlap with the commen=
 t
 you made here &#8220;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&#8221; 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).&nbsp; 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.<o:p></o:p></p>
 
 </div>
 
 </body>
 
 </html>
 
 --_000_3B704C911550A340BE8731F1331016D50300E87E92exchange01tor_--
>Unformatted:
