Date: Fri, 1 Apr 2011 15:14:47 +0000 (UTC) From: "Bjoern A. Zeeb" <bz@FreeBSD.org> To: freebsd-security@freebsd.org Subject: on "BSD derived RFC3173 IPComp encapsulation will expand arbitrarily nested payload" Message-ID: <alpine.BSF.2.00.1104011419360.6104@ai.fobar.qr>
next in thread | raw e-mail | index | archive | help
Hi, as some IPSec users might be worried about the "BSD derived RFC3173 IPComp encapsulation will expand arbitrarily nested payload" from http://seclists.org/fulldisclosure/2011/Apr/0 , here's some braindump: To be affected it's believed that you need to 1) manually compile in IPSEC (not done in GENERIC or the release), 2) have an entry for ipcomp in your security associations. You may also want to check what you negotiate with trusted peers if you use IKE. 3) an attacker needs to know the endpoint addresses (and the CID) to send you a nastygram. 4) if you require an outer ESP between peers, it's a matter of how much you trust your peer. FreeBSD will not panic, you may however be able to "store" packets in the network stack for IPv4 and see the netstat -s -p ipcomp packets in counter go up quickly. IPv6 has a net.inet6.ip6.hdrnestlimit of 15 by default and will throw away the packet after that many iterations. A mitigation change for the directly recursive case was just committed to HEAD: http://svn.freebsd.org/viewvc/base?view=revision&revision=220247 Similar patches for other branches (untested) are available: HEAD and STABLE/8 (include the V_irtualization): http://people.freebsd.org/~bz/20110401-02-ipcomp-head-8.diff STABLE/7: http://people.freebsd.org/~bz/20110401-03-ipcomp-7.diff STABLE/6 (KAME + FAST, where the FAST is the same as STABLE/7): http://people.freebsd.org/~bz/20110401-01-ipcomp-6.x.diff More details may follow. /bz -- Bjoern A. Zeeb You have to have visions! Stop bit received. Insert coin for new address family.
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?alpine.BSF.2.00.1104011419360.6104>