on "BSD derived RFC3173 IPComp encapsulation will expand arbitrarily
nested payload"
Bjoern A. Zeeb
bz at FreeBSD.org
Fri Apr 1 15:14:51 UTC 2011
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.
More information about the freebsd-security
mailing list