DragonFlyBSD

Hi,

find my assessment of the situation below - from the FreeBSD PoV.

On Wednesday 15 April 2009 19:34:08 rembrandt wrote:

Hello everybody,

I recently discovered a issue n the OpenBSD PF code and would like to know
if Dragonfly is affected or not.

The original advisory can get found at:
www.helith.net/txt/openbsd_4.3-current_pf_null_pointer_dereference_kernel_p
anic.txt

This advisory will get superseeded by another one because other vendors are
affected as well. I'd be happy if we could co-opperate to make a
co-ordinated release to reduce the confusion which happens if multiple
vendors update the same issue.

Please do let me know if and also if not DragonflyBSD is affected.
If it's affected when do you might plan patches and which versions are
affected?

<snip>
Further analysis suggests that the problem was introduced with OpenBSD's rev.
1.539 of pf.c (between OpenBSD 4.1 and 4.2) which means that NetBSD is
vulnerable while DragonflyBSD is probably in the clear.  The problem stems
from the unification of the rule processing in pf_test_rule().  With this
unification we apply ICMPv6 logic to IPv4 packets and vice versa.  Because the
handling logic asserts that the common code in pf_test⁶ has verified that
the packet contains a full ICMP header and has pulled up the mbuf up to that
point.  This assertion fails when the wrong AF-version of pf_test is leading
up to pf_test_rule.

Or the management overview:
No version of FreeBSD is vulnerable to this attack.  OpenBSD versions 4.2
through CURRENT (prior the fix of course) are vulnerable.  DragonflyBSD is not
vulnerable.  No released NetBSD version seems to be vulnerable, but the CVS
head and netbsd5-branch have been vulnerable between Wed Jun 18 09:06:27 2008
UTC and yesterday.

It might make sense to block IPv4 packets with ICMPv6 payload and vice versa -
I'd like input on that.  The patch from OpenBSD does just that and should
apply to FreeBSD with a bit of fuzz.

If you dislike my nmap sample nonroot posted some python script at
milw0rm.com.

:<snip>
:=46urther analysis suggests that the problem was introduced with OpenBSD's =
:rev.=20
:1.539 of pf.c (between OpenBSD 4.1 and 4.2) which means that NetBSD is=20
:vulnerable while DragonflyBSD is probably in the clear. =A0The problem stem=
:...

Ok, I'm posting here to close the issue.  Rembrandt and I conversed on
    IRC.  I located the patch OpenBSD applied to pf.c and checked similar
    code paths in our own (older) code.  We do not appear to be vulnerable.

-Matt