The following reply was made to PR misc/148463; it has been noted by GNATS.
From: Paul Miseiko <paul_mise...@rapid7.com>
To: "bug-follo...@freebsd.org" <bug-follo...@freebsd.org>,
"pmise...@gmail.com" <pmise...@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_--
_______________________________________________
freebsd-net@freebsd.org mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-net
To unsubscribe, send any mail to "freebsd-net-unsubscr...@freebsd.org"
