Bug #1338

OpenBSD PF issue

Added by rembrandt about 5 years ago. Updated almost 5 years ago.

Status:ClosedStart date:
Priority:NormalDue date:
Assignee:-% Done:

0%

Category:-
Target version:-

Description

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_panic.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?

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

Kind regards,
Rembrandt

History

#1 Updated by max about 5 years ago

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[6] 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.

#2 Updated by dillon about 5 years ago

:<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

Also available in: Atom PDF