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

Fri Jul 9 18:10:11 UTC 2010

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.

 --_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_--