Date: Fri, 9 Jul 2010 18:10:10 GMT From: Paul Miseiko <Paul_Miseiko@rapid7.com> To: freebsd-net@FreeBSD.org Subject: Re: misc/148463: [arp] ARP cache can be poisoned or polluted with ease. Message-ID: <201007091810.o69IAAUG042124@freefall.freebsd.org>
next in thread | raw e-mail | index | archive | help
The following reply was made to PR misc/148463; it has been noted by GNATS. 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> </o:p></p> <p class=3DMsoNormal>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.<o:p></o:p></p> </div> </body> </html> --_000_3B704C911550A340BE8731F1331016D50300E87E92exchange01tor_--
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?201007091810.o69IAAUG042124>